現在、ASP.net MVCアプリケーションを構築しています。このアプリケーションは、複数のモジュール（およびジェネリッククラスライブラリ）に分割されています。
最初のモジュールに作業単位パターンを実装しました。この作業単位クラスには、いくつかの異なるリポジトリーが含まれています。
しかし、モジュールごとに個別の作業単位クラスを用意するのは良い考えかどうか疑問に思いました。
3 に答える
0
EF は、それ自体で実装された UnitOfWork および Repository パターンを提供します。通常、それらはまさにあなたが望むものではなく、そのネイティブ EF リポジトリにいくつかのメソッドを追加するのは良いことのように思えますが、ほとんどの場合、面倒なことをする価値はありません。
プロジェクトが単純な場合、EF に基づいて独自のリポジトリを実装することはお勧めできません。多くの作業が追加されますが、それほど価値はありません。
EF に基づく UnitOfWork の実装は、まったく別の話です。私がそれを行うことができる唯一の理由は、「ソリューションのさまざまな部分にさまざまな UoW を持たせること」です。そうでなければ、本当に避けてください。
プロジェクトで事前に構築されたものを無視して、この両方のアプローチを追加しようとしました。私たちはモジュラー ソリューションを設計しており、最終的にいくつのモジュールが必要になるかさえわからなかったので、これは完全に合理的でした。システムがすでに実行されていて負荷が高い場合、システムに新しいモジュールを追加することを期待していました。そして、そのようなアプリケーションの開発には多くの時間がかかったと言えます。一部のモジュールからもう 1 つのエンティティにアクセスする必要があることに気付いた場合、いくつかの場所で変更が行われます。これは、設計が非効率的であることの最初の証拠です。
だから、KISSとYAGNIは反対。「これをプロジェクトに追加する必要があるか」という質問に悩まされている場合は、そうしないでください。多くの複雑さを追加するため、「素敵なデザイン」バイアスだけでなく、この部分を自分で実装する正当な理由が必要です。いつか必要になると思っても、その日まで待ちましょう。どの誤算がより悲惨なものになるかを見積もろうとすると、プロジェクトに新しいものを追加してから、既存のものを削除する方がはるかに簡単であると確信しています.
于 2013-01-31T08:13:06.853 に答える
0
モジュールごとに個別の Unit Of Work クラスを用意するのは良い考えですか?
私の最初の考えは、あるモジュールの作業単位が別のモジュールの作業単位とどのように異なるかということです。ドメインは永続性を無視し、データ層はビジネス ロジックを無視する必要があるためです。
たとえば、Entity Framework 自体に付属する UoW であるコンテキストを考えてみましょう。[コンテキストを作成しSaveChanges()、何かを実行し、それを呼び出して破棄すると、UoW として機能します]。おそらくアプリケーション全体に 1 つのコンテキスト クラスを使用できます。コンテキスト クラスでビジネス ロジックをプログラムするつもりはありません。そのため、モジュールごとにコンテキスト クラスを使用する理由はありません (各モジュールがデータベースの本当に異なる部分を使用する場合を除きます) (これはほとんど真実ではありません)。同じことが自分で作成した UoW にも当てはまります。
質問の範囲を少し超えていますが、EF は両方 (コンテキストと ) の基本的な実装を提供するため、独自の UoW とリポジトリ クラスが必要かどうかを自問することができますDbSets。
于 2013-01-30T18:34:19.433 に答える