MVC/MVP/MVVM - ビジネスロジックを構成する方法

Question

この投稿はin MVC/MVP/MVPC where do you put your business logic?と似ていますが、詳細を探しています。私は、ビジネスロジックの大部分が存在すべき場所としてModelに買収しました。しかし、モデルでは、アプリケーションの状態管理、データの永続性、リポジトリ、データ転送オブジェクト、その他の可能性について、私が理解している限り、内部で多くのことが起こっています。

私は超複雑なビジネスルールを持つアプリケーションを持っています。ユーザーがビュー内で特定のアクションを実行しようとすると、そのアクションを許可するかどうか、またはユーザーに追加情報の入力を求めなければならないかどうかを検証する約20種類のルールがあります。これらのビジネスルールをメソッドごとにコーディングして、テスト容易性とドキュメント化をサポートしたいと思います。これらのルールはリポジトリクラスにあるべきですか？おそらく、リポジトリの上にあるサービス層にありますか？ここで私がSQL、EF、またはnHibernateにLinqのようなORMソリューションを使用していることを念頭に置いて、ベストプラクティスは何ですか？

Answer 1

ビジネスルールの場合は、データベーステーブルに入れて変更するのが簡単です。

コード自体はビジネスルールのばかげていて、ルールコンテナの構造だけではルールの内容は気にしません。

以下のコメントについて、コード中心のアプローチを他の理由で制限する必要がある場合は、プロジェクトを大幅に高価にするだけです。

ルールが複雑になればなるほど、ハードコードされているのではなくテーブル駆動型の利点が増えます。あなたがそれに慣れていなければ、難しい部分はルールのモデルを思い付くことができます。モデルの構築後、開発は簡単です。

Answer 2

最初に、MVPではビュー内で状態を維持することができることを忘れないでください。そのため、モデルで起こっていることは少なくなります。

リポジトリアプローチとサービスレイヤアプローチの両方が適用可能かもしれません。私は、2つのテストアプリケーションを使って両方を同時に調べることに誘惑されると思う。あなたが行くにつれて、おそらく、一方が他方よりも適切であるという気持ちが得られます。その時点で、あなたは正しいアプローチに集中することができます。

これは無駄な努力のように思えるかもしれませんが、開発が本格的に始まると、アプローチを切り替える努力よりもはるかに少ないでしょう。 CSLA.NETは、ビジネスルールは面白いかもしれませんどのように処理するかで見持つ

Answer 3

： http://www.lhotka.net/cslanet/