デザインパターン：このコンセプトを理解し、それが私のプロジェクトにどのように適用されるのかを助けてください

Question

ここ数日、私はDAL/BLL/UIのアプローチを使って多くの研究を行いました。プロジェクト。以前は、BLLをUIにData Access Layer（LINQtoSQL dbml）に直接接続していませんでした。しかし、私はこれが良いアイデアだとは思っていません。ここで私は今（あるいは過去にも）働いています。さまざまなアプリケーションがあり、同じDAL/BLLを使いたいからです。

ほとんどの私のアプリケーションで、LinqtoSqlDataSource/GridViewを使用してdatacontextに接続して、すべての更新/編集などを処理すると、BLLはどのように役立ちますか？それぞれの新しいWebアプリケーションは、DAL/BLLを一意に変更する必要があり、同じDAL/BLLを使用する他のアプリに影響を与える可能性があります。これを行う正しい方法であるDAL/BLLの再利用ですか？何か不足していますか？

ビルドする必要があるときに、たとえば、ビルドされるさまざまなWebアプリケーションのセキュリティクラスをビルドする必要があると思います。しかし、私がLinqtosqldatasourceを使用すると、なぜBLLに接続するのは気になりますか？

DAL

• LinqToSQL DBMLのDataContext。
• LinqToSQLを使用すると、このデザインをどのように使用する必要がありますか？

BLL

• 会社によって使用される様々なウェブサイトのためのセキュリティ。
• クエリDALは何を返す（？）LinqToSQLDatSourceを使用した場合、様々な結果セットを処理機能（私は質問が不明である場合、これは申し訳ありませんBLL、で動作するべきか本当にわからないよ）

UI

• BLLのみ参照？

Answer 1

DALとBLLは、しばしば微妙ですが、重要な違いがあります。ビジネスの論理。馬鹿馬鹿しく思っていますが、区別が非常に緻密でありながら、アーキテクチャに大きな影響を与えるため、さらに説明しましょう。

フレームワークはLinq2SQLを使用して、非常に単純なオブジェクトを生成し、各オブジェクトは1つのテーブルに1つのレコードを表します。これらのオブジェクトはDTOです。彼らはライトワイト、フィールドのみを持つPOCO（Plain Ol 'CLR Object）クラスです。 Linq2SQLフレームワークは、これらのオブジェクトをDBデータからインスタンス化して水和する方法を知っており、同様に、DBレコードを作成または更新するSQLDMLに含まれるデータをダイジェストできます。しかし、このレベルでは、さまざまなオブジェクトのフィールド間の関係を管理するルールはほとんどまたはまったく知られていません。

実際のドメインモデルはこれよりもスマートにする必要があります。 SubTotalというOrderオブジェクトのプロパティがすべてのOrderLinesのすべてのExtendedCostの合計と等しくなければならないことを知るのに十分なほどスマートです。同様に、ExtendedCostはUnitPriceとQuantityの積である必要があります。現代の多くのプログラムでは、あなたのドメインは少なくともこの程度まであなたのBLLの一部です。 Linq2SQLによって作成されたオブジェクトは、特にSubTotalやExtendedCostを永続化していない場合は、このすべてを知っている必要はありません。 Linq2SQL DTOに頼っているのであれば、基本的には既知のアンチパターンである貧血ドメインモデル（Anemic Domain Model）に縛られています。ドメインオブジェクトが少なくとも内部的に一貫性を保つことができない場合、ドメインオブジェクトで動作するオブジェクトは、そのように保つために信頼されなければなりません。

UIはドメインについて知っている必要があります。または、読み書きの目的でドメインからデータを取得するための抽象的な方法を知っている必要があります（一般に、ドメインレイヤーおよび/またはLinq2SQL）。 UIは、中程度のサイズ以上のプログラムでDBについて知る必要はありません。ドメインオブジェクトはDAL内のオブジェクトへの参照を使用して水和することができます。または、DALのカスタムオブジェクトによって作成され、水和を行い、コントローラに与えられます。接続されたADOモデルとGridViewとの相互運用性は優れていますが、抽象化はできません。ドメインとUIの間にWebサービスレイヤーを挿入して、倉庫内のデータを扱うモバイルアプリケーションにUIを配置できるようにしたいとします。 Linq2SQLからオブジェクトを直接取得することはできないため、UIを再構築する必要があります。あなたはそれらをWebサービスから取得します。 Linq2SQLと通信しているControllerレイヤーがあれば、そのレイヤーをWebサービスと通信しているコントローラーに置き換えることができます。それは小さな違いのように聞こえる。あなたはいつも何かを変えなければなりません。しかし、今ではモバイルアプリとデスクトップアプリで同じUIを使っているので、THAT層の変更は2つの層が異なる方法でデータを取得するため、2回行う必要はありません。

Answer 2

これは私が今年1年間カタログアプリケーションで検討してきた大きな疑問です。私のための具体的なインスタンスは、パターンであなたを助けるかもしれません。

私にはショッピングカートの内容を表示するページがあります。 「初期段階」では、このページには、SQLストアド・プロシージャの結果が配置されたグリッドがあり、注文番号を指定すると、カートにアイテムがリストされていました。

今、私は '行'オブジェクトのコレクションを含む 'カート'のBLLオブジェクトを持っています。グリッドは同じですが、データソースはカートの行です。

なぜ私はこれをやったのですか？最初は、派手なデザインパターンのためではありません。各行のフィールドに基づいて処理する特殊なケースが非常に多く、同じカート内容のデータを表示するのに必要な場所が他にもありました。今、カートがリポジトリからロードされ、私のページにはそのリポジトリが何をするのか分かりません。ヘック、テストのために、それはハードコードされたカートデータです。

カートは、リポジトリを使用して行をロードします。各行には、データがどこから来たのかを知らずに、それ自体をマニピュレートするロジックがあります。

うまくいけばそれは役に立ちますか？