1

80% が複雑なビジネス ロジックで 20% が CRUD である、またはその逆のアプリケーションがあるとします。

過去に、私はある種のコマンドパターンを使用し、ComplexFooCMDorのようなクラスを持っていましEvenMoreComplexBarCMDたが、常にInsertFoo、UpdateFoo、DeleteFooおよびSelectFoosCMDいくつかのUpdateSomeValuesOfFooorで終わりましたSelectSomeFoos。これらはすべてBLLに住んでいました。

最近、あまり複雑でないビジネス ロジック アプリケーションで、次のようなクラスを持つサービス パターンを使用しましたFooServiceが、これらには期待されるinsertFoo、 、updateFooも含まれていselectSomeFooます。すべてのサービスでこれらのメソッドを使用したり、これらのメソッドをプレゼンテーション層に公開するためだけに存在するサービスを使用したりすることは、大量のボイラー プレート コードのように感じられます。

CRUD 部分とアプリケーションの残りの部分の両方に適合するパターンはありますか?それとも、アプリケーションのさまざまな部分に異なるパターンを使用する必要がありますか?

4

2 に答える 2

0

CRUD をビジネス ルールとは考えません。

「優先顧客に、その年の現在までの売上高の関数であるパー​​センテージ割引を与える」または「会社の住所がこの州のリストから」。

ビジネス ルールは、常に適切であるとは限りません。

于 2010-12-30T02:42:44.857 に答える
0

ビヘイビア駆動型開発について読むことを強くお勧めします。良い方向に導いてくれると思います。

このテーマに関して私が読んだ中で最も優れた本はThe RSpec Bookですが、Ruby 中心の例がたくさんあることに気が進まない場合は、好きな言語に基づいた他のリソースを参照することをお勧めします。

つまり、あなたの質問に対する答えは次のとおりです。テストでアーキテクチャをガイドし、アプリの必要な動作でテストをガイドします。

于 2010-12-30T02:43:22.027 に答える