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に配置しないと述べました。

アプリケーションは、ドメイン主導の設計原則から引き続きモデル化する必要があります。ORMを使用するか、ストレートJDBCを使用するか、SP（または何でも）を呼び出すかは問題ではありません。この場合、モデルをSPから抽象化する薄層がうまくいくことを願っています。別のポスターが述べ、あなたはサービスとしてのSPとその結果を表示し、あなたのドメインモデルに結果をマップする必要があります。

ストアドプロシージャを使用する実際の利点はありますか？

金融の世界（およびSarbanes-Oxley準拠が必要な場所）では、システムを監査して、システムが本来行うことを確実に実行できるようにする必要があります。これらの場合、すべてのデータアクセスがストアドプロシージャを介している場合、コンプライアンスを確保するのがはるかに簡単です。そして、アドホックSQLがすべて削除されると、物事を隠すのがはるかに難しくなります。これが「良いこと」になる理由の例については、ケントンプソンの古典的な論文Reflections on Trusting Trustを参照してください。

ストアドプロシージャは、クライアント側のSQLコードよりもはるかに効率的です。DBでSQLをプリコンパイルし、最適化を実行できるようにします。

アーキテクチャ的には、SPはタスクに必要な最小限のデータを返します。これは、転送されるデータが少ないことを意味します。このようなアーキテクチャを持っている場合、DBをサービスと考える必要があります（Webサービスと考え、各SPは呼び出すメソッドです）。このように操作することは問題ではありませんが、ORMはリモートデータをローカルであるかのように操作するためのガイドであり、注意しないとパフォーマンスの問題を引き起こすように仕向けます。

私は、SPを完全に使用し、DBがデータAPIを提供し、それを使用した状況にありました。その特定のアプリは非常に大規模で、驚くほどうまく機能しました。その後、SPについて悪いことを言うことはありません！

もう1つの利点があります-DBAがすべてのSQLクエリを作成し、DB内のすべてのリレーショナル階層を喜んで処理するため、必要はありません。

多くの場合、開発者はドメインモデルとしてORMオブジェクトを誤って使用します。

これは誤りであり、ドメインをDBスキーマに直接結び付けます。

本当に必要なのは、必要に応じて豊富な別のドメインモデルであり、ORMレイヤーを個別に使用することです。

これは、オブジェクトの各セット間のマッピングが必要であることを意味します。

Hibernateを使用する必要はありませんが、ドメインオブジェクトはどのように入力してもかまいません。適切な用語はdata-mapperです。永続化されたデータは、ドメインオブジェクトとはまったく異なる構造になる可能性が非常に高くなります。