30
なぜエンティティオブジェクトが必要なのですか？[閉まっている]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 4年前休業。 この質問を改善する 現在受け入れられているエンタープライズアプリケーション設計パラダイムのメリットについて、正直で思慮深い議論が必要です。 エンティティオブジェクトが存在する必要があるとは思いません。 エンティティオブジェクトとは、「個人」、「アカウント」、「注文」など、アプリケーションのために構築する傾向がある典型的なものを意味します。 私の現在の設計哲学はこれです： すべてのデータベースアクセスは、ストアドプロシージャを介して実行する必要があります。 データが必要なときはいつでも、ストアドプロシージャを呼び出して、SqlDataReaderまたはDataTableの行を反復処理します （注：Java EEを使用してエンタープライズアプリケーションも構築しました。Javaの人は、.NETの例を同等のものに置き換えてください） 私は反OOではありません。エンティティではなく、さまざまな目的で多くのクラスを作成します。私が書くクラスの大部分は静的ヘルパークラスであることを認めます。 私はおもちゃを作っていません。複数のマシンに展開された大規模で大量のトランザクションアプリケーションについて話している。Webアプリケーション、Windowsサービス、Webサービス、b2bインタラクション、という名前を付けます。 ORマッパーを使用しました。いくつか書いた。私はJava EEスタック、CSLA、および他のいくつかの同等のものを使用しました。私はそれらを使用しただけでなく、本番環境でこれらのアプリケーションを積極的に開発および保守しました。 私は、エンティティオブジェクトは、私たちの邪魔になっていることを戦いテストされたという結論になってきた、と私たちの生活は次のようになりますので、それらなしではるかに簡単。 この単純な例を考えてみましょう。正しく機能していないアプリケーションの特定のページに関するサポートコールがあり、フィールドの1つが本来のように永続化されていない可能性があります。私のモデルでは、問題を見つけるために割り当てられた開発者がちょうど3つのファイルを開きます。ASPX、ASPX.CS、およびストアドプロシージャを含むSQLファイル。この問題は、ストアード・プロシージャー呼び出しのパラメーターが欠落している可能性があるため、解決に数分かかります。しかし、どのエンティティモデルでも、必ずデバッガを起動し、コードをステップ実行し始めると、Visual Studioで15〜20個のファイルが開かれることになります。スタックの一番下に降りるまでに、開始した場所を忘れてしまいました。頭の中にあるのは、一度に多くの物だけです。ソフトウェアは、不要なレイヤーを追加することなく、非常に複雑です。 開発の複雑さとトラブルシューティングは、私の不満の片側にすぎません。 次に、スケーラビリティについて話しましょう。 開発者は、データベースと対話するコードを作成または変更するたびに、データベースへの正確な影響を徹底的に分析する必要があることを理解していますか？開発コピーだけでなく、本番を模倣しているので、オブジェクトに必要な追加の列が現在のクエリプランを無効にし、1秒で実行されていたレポートが2分で完了していることがわかります。選択リストに単一の列を追加したためですか？そして、現在必要なインデックスが非常に大きいため、DBAがファイルの物理レイアウトを変更する必要があることがわかりました。 抽象化によって物理データストアから離れすぎてしまうと、拡張が必要なアプリケーションで大混乱が発生します。 私は熱狂的ではありません。Linq to Sql、ADO.NET EF、Hibernate、Java EEなどへの強いプッシュがあるので、私が間違っていると私は確信している可能性があります。それが何であるか、なぜ私は自分の考えを変える必要があるのかを本当に知りたいのです。 [編集] この質問が再び突然アクティブになったようです。新しいコメント機能が追加されたので、いくつかの回答に直接コメントしました。お返事ありがとうございます。これは健全な議論だと思います。 おそらく、私がエンタープライズアプリケーションについて話していることをもっと明確にすべきでした。たとえば、誰かのデスクトップやモバイルアプリで実行されているゲームについてはコメントできません。 いくつかの同様の答えに対応して私がここで一番上に置かなければならないことの1つは、エンティティ/ ORMに移行する理由として、直交性と懸念の分離がよく引用されます。ストアドプロシージャは、私が考えることができる懸念の分離の最良の例です。ストアドプロシージャ以外のデータベースへのアクセスをすべて許可しない場合は、理論的にはデータモデル全体を再設計し、ストアドプロシージャの入力と出力を維持している限り、コードを壊さないようにすることができます。これらは契約によるプログラミングの完璧な例です（ "select *"を避けて結果セットを文書化する限り）。 業界に長く住んでいて、長命のアプリケーションを扱ってきた人に聞いてください。データベースが存続している間に、アプリケーションとUIのレイヤーがいくつ消えてしまったのでしょうか。データを取得するためにSQLを生成する4つまたは5つの異なる永続化レイヤーがある場合、データベースのチューニングとリファクタリングはどれほど難しいですか？何も変更できません！ORMまたはSQLを生成するコードは、データベースを完全にロックします。