WPF 4.0 および EF 4.0 テクノロジを使用してビジネス アプリケーションを開発するために使用できるアーキテクチャについて混乱しています。
私が最初に選んだのは、従来の N 層アーキテクチャで、UI、ビジネス ロジック レイヤー、データ アクセス レイヤーが分離された動作を備えていました。
このようにして、レイヤーごとに 3 つのプロジェクトを作成し、エンティティ/DTO 用に別のプロジェクトを作成します (各レイヤーはアセンブリです)。各レイヤーは、その上位レイヤーと下位レイヤーのみを参照します (つまり、UI は BLL を認識できますが、DAL を認識できません)。ただし、すべてのレイヤーは、通信目的でエンティティ/DTO アセンブリにアクセスできます。たとえば、DataGrid を使用して単純な CRUD フォームを作成したいときに問題が発生します。BLL は、Entity/DTO を返すときに DAL の DataContext を破棄します。これが、STE を使用せざるを得なくなった理由です。しかし、まだいくつかの問題があります。たとえば、BLL から UI に返されるエンティティごとに "StartTracking" メソッドを呼び出す必要があります。要するに、このパターンの信頼性について確信が持てないか、自動処理される CRUD フォームを忘れる必要があると思います。
DAL レイヤーでリポジトリ モデルを使用していますが、リポジトリ パターンについて検索すると、異なることがわかります。UIからDAL/Repository層とBLL/Services層(WCFでもWebServiceでもない層)の両方を参照するのも悪くないようで、(STEを使わずに)接続環境が持てます。
リポジトリから人を取得できるが、BLL またはサービスを使用して何かを実行できる例を確認します。
UI コード:
var person = new PersonRepository().GetPerson(10);
Bll.Salary.PaySalary(person);
-また-
var person = new PersonRepository().GetPerson(10);
Bll.Person.MarkAsAbsent(person);
またはそのようなもの...
このパターンを使用すると、DataContext が有効な間、接続された方法でエンティティ/DTO を UI に送信できます。
大きなプロジェクトでリポジトリ パターンを使用する方法を理解しているかどうかはわかりません。このように BLL またはサービスのクラスとメソッドに名前を付けるのは明確ではないと思います。さらに開発者は、リポジトリ メソッドまたは BLL/サービス メソッドを使用する場所、またはメソッドを作成する場所 (リポジトリまたは BLL/サービス) について混乱する可能性があります。
私は、エンティティ/DTO の変更を STE のように自動的に追跡する優れたアプローチを使用する N 層アーキテクチャを好みます。
そのような状況での最適なパターンをお勧めするか、またはそれに関する優れた本やドキュメントを参照してください.