ASP.NET MVCとEntity Frameworkでアーキテクチャ設計を理解しましたか？

Question

現在、Active DirectoryとSQL Server 2008を使用しているイントラネットWebサイトで作業しています。ASP.NETのMVCデザインパターンを使用して、データアクセスに関するプロジェクトの適切なアーキテクチャを取得する方法を理解しようとしています。一部はエンティティフレームワークを使用しています。私は間違った方向に行かないために数日間苦労してきました。私は私の会社の唯一の開発者だということを知っています。これは私の最初の経験であり、最近のフレームワークについては誰も知りません。私はアーキテクチャとそれを正しく行う方法について読んだことがありますが、すべてを正しく把握しているかどうかはわかりません（How do architect an ASP.Net MVC app with EF?）。

Controller(MVC Project) ---uses---> Service Layer (Project) ---uses--> EFDal (Project) 
      ^      |  ^      | 
       |       |  |       | 
       |<-------<-----returns ViewModel |<---------<------returns Query Result 

EFDalがEntityFrameworkデータアクセス層である：ここで

は、私は（私の描画スキルはご容赦）、やって、独自のプロジェクトを持つそれぞれの層を考えていたものです。

私が理解したところでは、サービスレイヤにはDALを呼び出すメソッドが含まれており、DALはデータにアクセスするために使用されます。

私のアプローチに間違いがありますか？
私はサービスレイヤーと言っていますが、すべての操作を含んでいますか？ （例：DB内のユーザーの検索 - >サービスレイヤーが値を返すEFDalを呼び出すことで、検索を起動し、順番にサービス層をコントローラーにViewModelにを返す） （参照：Creating a Service Layer for my MVC application?）

最後に、私のサービス万一レイヤークラスは永続化の目的でインタフェースを実装しますか？

私たちは私たちのプロジェクトにMVCパターンを使用していました。小規模なプロジェクトに取り組んでいたため、新しいプロジェクトでソリューションを拡張する必要はありませんでした。ここで私はアーキテクチャが悲惨な保守性に終わると誤解しているように感じます。ご協力いただきありがとうございます！

Answer 1

あなたはほぼ正しい方向にいます。ただし、この場合のViewModelはアプリケーション層、つまりMVC層に存在する必要があります。サービス層は、より一般的にはDTOとして知られるデータ転送オブジェクトを返す必要があります。

Viewのために構築されたシンプルなPOCOクラスとしてViewModelのだと思うが、それはあなたのサービス層からのさまざまなサービスによって返された様々なDTOのコレクションすることができます。 DTO

1. の

   利点は、あなたが直接あなたのドメインエンティティ、すなわちあなたのEntityFramework POCOクラスを暴露されていません。しかし、DTOを一緒に避けるようにプロジェクトを小さくすることができます。

2. 今後、iPhoneアプリケーションの場合はWebAPI機能をMVCプロジェクトに追加することにしました。新しいアプリケーションでは、サービス層も消費するWebAPIが使用されます。サービス層コードの大部分は、DTOクラスを返し、用に構築されたViewModelクラスではないため、再利用できます。

データアクセス層には、このユーザーよりも優れた説明はありません。Entity FrameWork With Repository Pattern

プロジェクトの構造については、私はタマネギのアーキテクチャをお勧めします。 Onion Architecture。この記事を十分に理解できれば、すべての設定が必要です。