質問: 私は新しいプロジェクト(非企業的)を始めています。そして、私は今、どのようにすばらしい建築になるのか知りたいと思います。 今私が計画しているのは、使用することです: * ASP.NET MVC 4.0 * SQL Server 2008または2012 * EF 5.0、.NET 4.5、Dapper * リポジトリパターンの実装(これはhttp://code.google.com/p/ef4prs/です ) * オートファック付きDI * オートマッパ * WCFサービスレイヤー(将来のモバイル実装用) (何かが間違っているなら、私を修正)の流れを確認する: **コントローラは** **(、BusinessLayerを**呼び出すこと**、ApplicationServiceを**呼び出しUnitWork /リポジトリと**DALを**呼び出すこと、それは**、EF**または**Dapperの**上でクエリを実行すると、リポジトリでの具体的な方法からDapperのを照会することが正しいのですか? )、結果は自動的に**DTOに**マップされ、 **Controller**に返され、 **ViewModelに**必要なものをコピーしてViewを返します。 私が言ったように、サイトはトラフィックが多いと計画されています。この場合、上記の項目のいずれかがパフォーマンスを低下させる可能性がありますか?あるいは、この組み合わせはさらに何かを漏らすのでしょうか?私はEFを捨て、Dapperだけを使うべきですか?トラフィックのためにサービスレイヤーがパフォーマンスを低下させる恐れがあります。 そして最後に、私はこのアーキテクチャが不要かどうか、あるいは貧弱かどうかはわかりません。 それはたくさんの質問ですが、焦点は、中規模のWebサイトのための "オーバーアーキテクト"ではない素晴らしいソリューションを知ることです。 英語のために申し訳ありません
回答: あなたの質問はかなり主観的です。すべての設定がうまくいくかもしれない多くの設定があります。私はあなたにいくつかの推奨事項を与えることができます。 DapperとのEFのミキシングとマインドフィールは、少し難しいかもしれません。理論的には、Dapperを使ってオブジェクトを取得し、 `DbContext`オブジェクトを`Attach`して更新できる`DbContext`です。しかし、私の経験ではしばしばうまくいかない。私たちはEFを使い始めたのですが、高速クエリーのためにDapperにゆっくりと移動しました。私はEFを使用して更新/挿入を続けることができると考えましたが、私は自分自身の挿入/更新トラッキング(驚くほど簡単)を終了しました。 EFの使用。 後で、私はそれを選んでそれをつけることを勧めます。 EFは.NET 4.5の下でかなり速くなければなりません。 Dapperほど高速ではないので、純粋なDapperルートは悪いことではありません。 あなたが検討できる他の技術: * ServiceStack( ウェブサービス) 。強く推奨され、構成は低く、使いやすく使いやすいです。 * ASP.NET MVC Web-API(Webサービス) 私はそれについての経験はない。 * ThisMember(マッパー、 *免責事項:私自身のライブラリ* ) 。 AutoMapperよりずっと速く(10〜100倍)、私の意見では使いやすくなりました。