ORMはリッチドメインモデルの作成を可能にしますか？
私のほとんどのプロジェクトでHibernateを約8年間使用した後、私はその使用を思いとどまらせ、ストアドプロシージャを介してのみDBと対話するアプリケーションを求めている会社に行きました。 数週間これを行った後、私が構築し始めているアプリケーションのリッチドメインモデルを作成することができず、アプリケーションは（恐ろしい）トランザクションスクリプトのように見えます。 私が発見した問題のいくつかは次のとおりです。 ストアドプロシージャは最小量のデータを読み込むだけなので、オブジェクトグラフをナビゲートすることはできません。つまり、フィールドが異なる類似したオブジェクトがある場合があります。たとえば、顧客からすべてのデータを取得するストアドプロシージャと、顧客からアカウント情報といくつかのフィールドを取得するストアドプロシージャがあります。 多くのロジックは最終的にヘルパークラスになるため、コードはより構造化されます（エンティティは古いC構造体として使用されます）。 ストアドプロシージャから結果セットを抽出し、エンティティに配置するフレームワークがないため、より退屈な足場コード。 私の質問は： 誰もが同様の状況にあり、ストアプロシージャアプローチに同意しませんでしたか？あなたは何をした？ ストアドプロシージャを使用する実際の利点はありますか？「誰もドロップテーブルを発行できない」という愚かな点は別として。 ストアドプロシージャを使用してリッチドメインを作成する方法はありますか？オブジェクトグラフをナビゲートできるように、AOPを使用してエンティティにDAO /リポジトリを挿入する可能性があることを知っています。ブードゥー教に非常に近いので、このオプションは好きではありません。 結論 まず、答えてくれてありがとう。私が到着した結論は、ORMは（一部の人が述べたように）リッチドメインモデルの作成を有効にしないが、（多くの場合繰り返し）作業の量を単純化するということです。以下は結論のより詳細な説明ですが、ハードデータに基づいていません。 ほとんどのアプリケーションは、情報を要求して他のシステムに送信します。これを行うには、モデル用語で抽象化（ビジネスイベントなど）を作成し、ドメインモデルがイベントを送受信します。通常、イベントにはモデルからの情報の小さなサブセットが必要ですが、モデル全体ではありません。たとえば、オンラインショップでは、支払いゲートウェイはユーザーに請求するためにユーザー情報と合計を要求しますが、購入履歴、利用可能な製品、およびすべての顧客ベースは必要としません。そのため、イベントには小規模で特定のデータセットがあります。 アプリケーションのデータベースを外部システムとして使用する場合は、ドメインモデルエンティティをデータベースにマッピングできる抽象化を作成する必要があります（NimChimpskyが言及したように、データマッパーを使用）。明らかな違いは、各モデルエンティティのデータベース（レガシースキーマまたはストアドプロシージャ）へのマッピングを手作業で作成する必要があることです。2つは同期していないため、1つのドメインエンティティが部分的にマッピングされる可能性がありますデータベースエンティティ（たとえば、ユーザー名とパスワードのみを含むUserCredentialsクラスが他の列を持つUsersテーブルにマップされる）、または1つのドメインモデルエンティティが複数のデータベースエンティティにマップされる場合があります（たとえば、1対1の場合テーブルに1つのマッピングがありますが、1つのクラスにすべてのデータが必要です）。 エンティティが少数のアプリケーションでは、エンティティを横断する必要がない場合、追加の作業量は少ないかもしれませんが、エンティティを横断する条件付きの必要がある場合は増加します（したがって、ある種の「怠lazな」読み込み」）。アプリケーションが成長してより多くのエンティティを持つようになると、この作業は増加するだけです（そして、非線形に増加すると感じています）。ここでの私の仮定は、ORMを再発明しようとしないことです。 DBを外部システムとして扱うことの利点の1つは、アプリケーションの2つの異なるバージョンを実行し、各アプリケーションのマッピングが異なる状況を回避できることです。これは、本番環境への継続的な配信のシナリオでより興味深いものになります...しかし、これは、ORMでもそれほどではないかもしれません。 開発者は、データベースにアクセスできなくても、悪意のあるコードを挿入するだけで、システムに格納されている情報のほとんどではなくてもほとんどを取得できることに基づいて、セキュリティの側面を無視します。親愛なる主よ、顧客のクレジットカードの詳細を記録する行を削除するのを忘れたとは信じられません！）。 小さな更新（6/6/2012） ストアドプロシージャ（少なくともOracleの場合）では、テーブルの構造を変更するとプロシージャとトリガーが無効になるため、ダウンタイムがゼロの連続配信のようなことはできません。したがって、DBが更新されている間、アプリケーションもダウンします。Oracleは、このためのEdition-Based Redefinitionと呼ばれるソリューションを提供しますが、この機能について私が尋ねた少数のDBAは、実装が不十分であり、運用DBに配置しないと述べました。