1

私は、単一のサーバー (データベースを含む) に常駐する WebForms (MVC ではない) アプリケーションの作業を開始し、(私が思うに) かなり標準的な N 層アーキテクチャを使用して設計することにしました。

データレイヤー

  • Entity Framework 4 と汎用リポジトリ/作業単位パターンを使用します。
  • ストアド プロシージャを広範囲に使用します (これは権限によって私に与えられた要件です)。
  • ビジネス オブジェクト層への参照を保持して、BO との間でデータをやり取りします。

ビジネスオブジェクト「レイヤー」

  • コードファースト POCO。
  • それらが持つ唯一の動作は検証のものです(名前はnullではない、数量は正の整数でなければならないなど)。
  • 他のレイヤーを参照したり、データがどこから来ているかを気にしたりしません。

ビジネスロジック層

  • UI レイヤーとデータ レイヤーの間の仲介者として機能し、レコード変更時の電子メール通知などの追加のビジネス「ルール」を実行するビジネス サービスが含まれます。
  • データ層とビジネス オブジェクト層への参照があります。
  • UI との間で BO を渡します。

UIレイヤー

  • 通常の UI 要素 (Web フォーム、JavaScript、スタイルシートなど) をすべて保持します。
  • ビジネス ロジックおよびビジネス オブジェクト層を参照します。

いくつか質問があります...まあ、実際にはたくさんあります:/

  1. アプリケーションが複数のサーバーにまたがって配置される場合、Web サービスを使用する場合、またはビューに渡されるデータが複数のタイプのビジネス オブジェクトのコンパイルである場合、DTO を使用する利点はわかりますが、本当に必要ですか?すべてが同じ物理マシン上にある場合、BLL と UI の間で渡す前に、すべての BO を DTO に変換しますか? ほとんどの DTO は、「クラス名の最後にコピー、貼り付け、「DTO」を追加する」作業になるので、本当に無意味な時間の無駄のように思えます。最終的には、メンテナンス コストが高くなり、パフォーマンスがわずかに低下するだけです (1 つではなく、2 つのクラスを同じコードで更新する必要があります)。
  2. DTO が必要になる場合があると仮定すると、DTO に検証を追加することは許容されますか (つまり、名前は null であってはならず、数量は正の整数でなければなりません)。
  3. FluentValidation のようなものを使用して、検証コードを独自のクラス ライブラリに分離することがベスト/ベター プラクティスでしょうか? 私がこれを行った場合、BO は基本的に DTO になり、動作がゼロになるためです..その場合、貧血ドメインモデルになってしまうようです?
  4. BO が EF によって使用されている場合、データ レイヤーがビジネス オブジェクト レイヤーを参照することは許容されますか?
  5. 私のサービスの "Find( predicate )" と "FindAll( ) " メソッドが同じストアド プロシージャ (すべてのレコードをプルする) を使用していると見なすと、次のようなことを意味します:

    List<Foo> myFoo = FooService.Find( f => f.Country == "Australia" && f.Status = OrderStatus.New );
    

実際にはストアド プロシージャを介してすべてのレコードを取得し、事後にフィルタリングを実行しますか? その場合、必要なレコードのみを取得するストアド プロシージャを使用すると同時に、linq 式の使用を許可するにはどうすればよいでしょうか (&&、||、!= などを許可する必要があります)。これは(sprocsを捨てることなく)可能ですか?

4

1 に答える 1

0

モノリシックなアプリになるとオーバーアーキテクチャだと思います。YAGNI と DRY に従って、サービスが BO を返すようにするだけです。また、WebForms を使用する場合は MVP パターンを使用することをお勧めします。「サービス レイヤー」を避けて、代わりにドメイン駆動設計 (DDD) を使用することもお勧めします。

http://en.wikipedia.org/wiki/Domain-driven_design

http://en.wikipedia.org/wiki/Don 't_repeat_yourself

http://en.wikipedia.org/wiki/You_ain 't_gonna_need_it

http://www.codeproject.com/Articles/23562/Building-an-MVP-Framework-for-NET-Part-1-The-Basic

MVP の実装は非常に簡単です。説明は常にコンポーネントと矢印でいっぱいになり、サンプル実装は常に物事を複雑にしようとします (理由はわかりません) が、実際には関心を分離するための単純なパターンであり、実際に機能します :)

それが役に立てば幸い :)

于 2012-05-13T15:06:41.453 に答える