建築デザイン
私がまとめている新しいアーキテクチャのいくつかの提案を探しています。
使用するツール:
- 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を使用している場合、ドメインモデルはありません。アイデアについて少し混乱しています。
申し訳ありませんが、これは非常に長いです。どんな答えでも大歓迎ですが、包括的な答えは指数関数的にもっと役に立ちます。さまざまなことを行うためのツールを選ぶことはできますが、それらを正しく連携させることは難しい部分です。
批判は大歓迎です!
皆さん、ありがとうございました