私は最近、Anemic Model を使用して n 層アプリケーションを作成していることに気付きました。これは適切な OO の方法ではないと多くの人が主張します (実際にはアンチ パターンです)。
そのため、代わりにドメイン駆動設計を適用しようとしています。
objectdatasource を使用して、グリッド ビューなどのコントロールをビジネス オブジェクトにバインドすることに慣れています。ドメイン モデルで objectdatasource を使用する方法について混乱しています。objectdatasource には貧血モデルが必要ですか?
私はすべての objectdatasources を削除することを検討していましたが、(特にコードのデバッグと例外処理に関しては) とにかく時々負担になることがわかりましたが、物事を行うための「適切な」方法が何であるかを知りたいです。
ASP.NET の経験はあまりありませんが、一般的なデータバインディングはうまくいくと思います。それはあなたに多くの利益をもたらすので、安易に捨てないでください。
重要なのは、懸念事項を分離することです。データをレンダリングする方法は、ドメイン モデル自体とは関係がないため、ドメイン モデルをビューにマップする特殊なプレゼンテーション ロジック レイヤーを用意することをお勧めします。
これは、ドメイン モデルをテクノロジーに中立に保つことができるため、多くの予期せぬ方法でドメイン モデルを公開できることを意味します。将来、ドメイン モデルに基づいて WCF サービス、バッチ ジョブ、または WPF/SL リッチ クライアントを実装するよう求められると想像してください。特定の UI テクノロジ (ASP.NET など) に関連する多くの特殊性を引きずることなく、このような予期しない要件を処理できる必要があります。
ビューごとにビューモデルまたはプレゼンテーション モデルがある場合、それらのモデルに対してデータバンディングを使用できます。これが ASP.NET でどの程度うまく機能するかはわかりませんが、ASP.NET MVC と WPF の両方で魅力的に機能し、そのサポートは現在 Silverlight 4 に組み込まれています...
個人的には、オブジェクトの貧血を判断するときに持続性を除外することについてはあまり心配していません。オブジェクトのビジネス動作は、オブジェクトが永続的であるかどうか、およびオブジェクトがどのように永続化するかと直交している必要があります。
動作は、根本的な問題の解決に役立つ機能に関するものでなければなりません。転送値オブジェクトであり、CRUD操作について心配しないオブジェクトを設計するときは、これに集中します。