私は、単一のサーバー (データベースを含む) に常駐する WebForms (MVC ではない) アプリケーションの作業を開始し、(私が思うに) かなり標準的な N 層アーキテクチャを使用して設計することにしました。
データレイヤー
- Entity Framework 4 と汎用リポジトリ/作業単位パターンを使用します。
- ストアド プロシージャを広範囲に使用します (これは権限によって私に与えられた要件です)。
- ビジネス オブジェクト層への参照を保持して、BO との間でデータをやり取りします。
ビジネスオブジェクト「レイヤー」
- コードファースト POCO。
- それらが持つ唯一の動作は検証のものです（名前はnullではない、数量は正の整数でなければならないなど）。
- 他のレイヤーを参照したり、データがどこから来ているかを気にしたりしません。
ビジネスロジック層
- UI レイヤーとデータ レイヤーの間の仲介者として機能し、レコード変更時の電子メール通知などの追加のビジネス「ルール」を実行するビジネス サービスが含まれます。
- データ層とビジネス オブジェクト層への参照があります。
- UI との間で BO を渡します。
UIレイヤー
- 通常の UI 要素 (Web フォーム、JavaScript、スタイルシートなど) をすべて保持します。
- ビジネス ロジックおよびビジネス オブジェクト層を参照します。
いくつか質問があります...まあ、実際にはたくさんあります:/
- アプリケーションが複数のサーバーにまたがって配置される場合、Web サービスを使用する場合、またはビューに渡されるデータが複数のタイプのビジネス オブジェクトのコンパイルである場合、DTO を使用する利点はわかりますが、本当に必要ですか?すべてが同じ物理マシン上にある場合、BLL と UI の間で渡す前に、すべての BO を DTO に変換しますか? ほとんどの DTO は、「クラス名の最後にコピー、貼り付け、「DTO」を追加する」作業になるので、本当に無意味な時間の無駄のように思えます。最終的には、メンテナンス コストが高くなり、パフォーマンスがわずかに低下するだけです (1 つではなく、2 つのクラスを同じコードで更新する必要があります)。
- DTO が必要になる場合があると仮定すると、DTO に検証を追加することは許容されますか (つまり、名前は null であってはならず、数量は正の整数でなければなりません)。
- FluentValidation のようなものを使用して、検証コードを独自のクラス ライブラリに分離することがベスト/ベター プラクティスでしょうか? 私がこれを行った場合、BO は基本的に DTO になり、動作がゼロになるためです..その場合、貧血ドメインモデルになってしまうようです?
- BO が EF によって使用されている場合、データ レイヤーがビジネス オブジェクト レイヤーを参照することは許容されますか?
私のサービスの "Find( predicate )" と "FindAll( ) " メソッドが同じストアド プロシージャ (すべてのレコードをプルする) を使用していると見なすと、次のようなことを意味します:
List<Foo> myFoo = FooService.Find( f => f.Country == "Australia" && f.Status = OrderStatus.New );
実際にはストアド プロシージャを介してすべてのレコードを取得し、事後にフィルタリングを実行しますか? その場合、必要なレコードのみを取得するストアド プロシージャを使用すると同時に、linq 式の使用を許可するにはどうすればよいでしょうか (&&、||、!= などを許可する必要があります)。これは（sprocsを捨てることなく）可能ですか？