2

最も一般的な開発シナリオ用に再利用可能なコンポーネントを作成しようとしています。

ドメインオブジェクトとデータオブジェクト（dc-serializable）をドメインオブジェクトにカプセル化するための汎用プレゼンテーション層を作成しました。また、すべてのdomainobject-instancesを参照したままにするある種のdomainstate/contextもあります。ドメインオブジェクトには、オンデマンドで最初にアクセスされたときにデータソースから入力される特別なコレクションがあるという考え方です。正確には「DDD」ではないと思いますが、うまくいくようです...

とにかく、今私はdatacontextとdatasource-partで立ち往生しています。私は、データを保存し、データソースと対話する方法について多くのことを考えてきました。zipファイル、sql-server、sql-lite-files、entity framework、nhibernate、linqtosql、mongodbなどのxmlで、何を使用するかを決めることができません。データソースとデータコンテキストの両方を抽象化し、代わりに各アプリケーションで何を使用するかを決定する必要があるようです。重要なことは、特定のフレームワークにハードな依存関係を埋め込まないことです。

データコンテキストとデータソースを抽象化しても、既存のあらゆる種類のフレームワークでうまく機能し、簡単に機能するのは現実的ですか？私はこれを間違って考えていますか？これは行き止まりですか？

私が必要としているのは（私が思うに）、特定の基準に一致するオブジェクトのデータコンテキストをクエリできるようにするためのドメイン状態だけです。オブジェクトグラフ全体を処理できるのか、個々のデータオブジェクトのみを処理できるのか、具体的なタイプではなく一部の汎用オブジェクトのみを処理できるのか、リクエストごとに複製する必要があるのか​​はわかりません。これについて考え始めると、とても混乱します...

ああ

アップデート：

DataContext / DatabaseContext（たとえば、EntityFramework）は、オブジェクトをメモリにキャッシュし、クエリを実行し、データソースとの間でデータをフェッチおよび保存し、型指定されたオブジェクトをコンシューマーに返すためのモジュール/レイヤーとして表示されます。これは正しいですか？

リポジトリパターン（DDD）と私のDataContextの違いは何ですか？

アップデート2：

基本的に、これは私のモデルです（良いか悪いか？）：

DataSource-> DataContext / DataObject-> DomainState / DomainObject-> Presenter

4

2 に答える 2

2

データソースとデータコンテキストの両方を抽象化し、代わりに各アプリケーションで何を使用するかを決定する必要があるようです。重要なことは、特定のフレームワークに強い依存関係を埋め込まないことです

それがリポジトリパターンです。

リポジトリ パターン (DDD) と私の DataContext の違いは何ですか?

リポジトリは、ストレージ アクセスに関連するすべてを抽象化する方法です。アプリのニーズに応えるように設計されており、アプリの残りの部分で認識されているオブジェクトを受信/送信します。DataContext は、それ自体がリポジトリの実装の詳細である EF の実装の詳細です。

リポジトリには 2 つの目的があります

  1. インターフェイスのみを公開することで、データの保存方法を変更できるようにします (db の変更、xml ファイルの使用など)。

  2. これにより、データベース中心のアプローチの「圧政」から解放され、ドメインに集中できます。これは非常に重要です。最初に db スキーマを使用してアプリの設計を開始するたびに、必然的にアプリの残りの部分をアプリに合わせようとし、データベース スキーマを模倣した貧弱なドメインが作成されるからです。

DataSource->DataContext/DataObject->DomainState/DomainObject->Presenter

どのアプリでも、基本的にクエリ (読み取り) と更新 (書き込み) があります。99% では、読み取りにはビジネス ルールがない (動作がない) ため、ドメインは書き込みにのみ適用されます。表示する関連データを選択するだけです。

書き込みの場合は、このフローをお勧めします

ViewModel (入力) -> ドメイン処理 (エンティティ、サービスなど) -> ドメイン リポジトリ

アプリに応じて、さまざまな方法でビュー モデルからドメイン エンティティにアクセスできます。ドメインが非常に単純な場合、ドメインはほとんど必要ありません。ビュー モデルはドメインになり、多くの場合、db スキーマと同じになります。

読み取り用

クエリ リポジトリ -> ViewModel (プレゼンター)

もちろん、コントローラーは通常クエリ リポジトリを呼び出し、レポから受け取ったデータから目的のビュー モデルを組み立てる場合があります (単純なケースでは、レポは正確にビュー モデルを返します)。

于 2012-03-14T08:28:59.910 に答える
2

おそらく、いくつかのコード例を投稿できますか? あなたがやろうとしていることを正確に理解するのは少し難しいですが、私はあなたの質問やコメントのいくつかに答えようとします.

「ドメインオブジェクトには、最初にアクセスされたときにオンデマンドでデータソースから取り込まれる特別なコレクションがあるという考えです。それは正確には「DDD」ではないと思いますが、うまくいくようです...」

これは遅延読み込みとどう違うのですか? なぜ特別な種類のコレクションが必要なのですか? そして、これはどのように DDD と相関するのでしょうか?

データコンテキストとデータソースを抽象化して、既存のあらゆる種類のフレームワークで適切かつ簡単に機能させることは現実的ですか? 私はこれについて間違って考えていますか？これは行き止まりですか？

いいえ、そうではありません（これは行き止まりです）。永続化テクノロジへの参照を持たないドメイン モデルを簡単に作成できますが、選択した orm マッパーの制約について考える必要があります。たとえば、EF は列挙型をサポートしていませんが、nhibernate はサポートしています。さらに、これを一般化することで何が得られますか? 一度マッパーを選択したら、マッパーを切り替えることはありません。切り替えたとしても、ソリューションの残りの部分が適切であれば、ほとんど問題なく切り替えられるはずです (ISession/DbContext/その他のものを分散させないでください)。

「リポジトリ パターン (DDD) と私の DataContext の違いは何ですか?」

たとえば、「私のDataContext」と言うときにEF DbContextを意味する場合、違いは、DbContextが特定の永続化テクノロジの表現であるのに対し、リポジトリはテクノロジに依存しない永続化の抽象化です。エンティティを保持するものの表現ですが、それを実現するために使用されるテクノロジ (xml、データベース、ファイル ストレージ、インメモリなど) を公開するべきではありません。

一般的な注意として、私はこれを自分で行いません。一般化は難しく、ほとんどの場合、膨大な時間がかかります。開発者は一般化と「コードの再利用」の考え方を好みますが、コードの難読化と複雑さ以上のものをソリューションに導入することはめったにありません。機能するものを作成することを目指し、繰り返し始めたら一般化します。これを事前に作成しようとしないでください。ほとんどの場合、役に立たない (またはそれに近い) ものになってしまいます。それに、あなたが何をテーブルに持ってきたのかわかりません。今日の orm マッパーは非侵入的で使いやすいです。また、一般的なプレゼンテーションレイヤーについても言及していますが、プレゼンテーションほど具体的なものはないため、これによるメリットもわかりません（ただし、コードを投稿したり、もう少し説明したりするとよいでしょう）。

于 2012-03-14T08:33:39.950 に答える