2

建築デザイン

私がまとめている新しいアーキテクチャのいくつかの提案を探しています。

使用するツール:

  • MVC 4(MVC 3の例がある場合は、それで十分です)
  • Entity Framework 4.1(EF)
  • リポジトリパターン
  • 作業単位
  • POCO(T4自動生成)
  • WCF(CRUD関数の場合。具体的なサービスクラスを使用してデータを取得します)
  • 依存性注入(Ninject)
  • モック(Moq)

他の良いツールは私に知らせてくれます。

ORMにEFを使用することに固執し、EFが価値がないことが判明した場合は、NHibernateが2番目になります。

私がこれまでにしたこと

1)プレゼンテーションプロジェクト(MVC4、DIサービス、サービスチャネル設定、モデルの表示)->ドメインプロジェクトを参照(2)

2)ドメインプロジェクト(POCOエンティティ、ドメインオブジェクト、サービスインターフェイス)->参照ビジネスプロジェクト(3)

3)ビジネスプロジェクト(WCFサービス、具体的なサービスクラス、作業単位)->参照データプロジェクト(4)

4)データプロジェクト(EF、コンテキスト+ .edmx、リポジトリとそのインターフェイス)->データベースを確認します

質問1:これは良いプロジェクトの内訳ですか? 質問2:これは、言及された項目のいずれかを括弧で囲むのに適した場所ですか? 質問3:私が完全に省略した場所にあるべきものはありますか?

いくつかの補足事項: 100,000レコードを簡単に超える、取得する大規模なレコードセットがあります。WCFサービスを経由するのではなく、パフォーマンスを向上させる具体的なサービスクラスを呼び出すだけです。最大メッセージサイズに加えて、WCFを介してレコードを取得するのに2倍の時間がかかりました。

質問4:これを行うためのより良い方法はありますか?パフォーマンスが重要です。再利用性はそうではありません

ドメインオブジェクトには、対応するPOCOに対応する単一の属性があります。例:「Order」というドメインオブジェクトがあります。すべての属性を保持する「OrderPOCO」という単一の属性があります。ドメインオブジェクトには検証メソッドがあり、必要なCRUD関数を参照します。

質問5:「このレコードはすでに存在しますか」などの複雑な検証をどこに配置する必要がありますか?それはサービス自体で行うことができますか?

質問6:ドメインオブジェクトも必要ですか?他のほとんどの例では、私が知る限り、POCOを使用している場合、ドメインモデルはありません。アイデアについて少し混乱しています。

申し訳ありませんが、これは非常に長いです。どんな答えでも大歓迎ですが、包括的な答えは指数関数的にもっと役に立ちます。さまざまなことを行うためのツールを選ぶことはできますが、それらを正しく連携させることは難しい部分です。

批判は大歓迎です!

皆さん、ありがとうございました

4

1 に答える 1

2

質問1、2、および3:3つのレイヤーのみを含むアーキテクチャレイアウトをよく見ました。ただし、ドメインプロジェクトレイヤーとビジネスプロジェクトレイヤーを分離して分離したままにし、一方を変更しても他方に影響を与えないようにする場合は、もちろん、それらを別々のアセンブリに保持する必要があります。ただし、POCOエンティティ、作業単位、および具体的なサービスの実装は、多くの場合、ドメインおよびアプリケーションのビジネスルールに非常に密接に関連しているため、これら2つのレイヤーを1つのアセンブリにマージすることを検討できます。

リポジトリインターフェイスをbusinnesレイヤーで上に移動し、businesレイヤーからデータレイヤーへの参照を削除し、代わりにUIレイヤーにデータレイヤーを参照させます。次に、UIレイヤーは、具体的な再投稿をドメイン/ビジネスレイヤーに挿入します。これにより、ドメイン/ビジネスレイヤーからテクノロジーに依存するデータアセンブリへの参照を排除できます。

質問4: パフォーマンスが重要な場合は、具体的なサービスクラスと呼びます。

質問5: 「複雑な検証」の意味がわかりません。

質問6: EFは、POCOを自動生成し、.edmx以外のアセンブリに配置できます。この記事を参照してください。このように、POCOはT4テンプレートのみに依存し、EFにハード結合されません。

于 2012-06-03T20:32:55.927 に答える