デザインパターン：この概念とそれが私のプロジェクトにどのように適用されるかを理解するのに役立ちます

Question

過去数日間、私はそれが私のプロジェクトにどのように適用されるかを非常に明確に理解することなく、DAL/BLL/UIアプローチを使用して多くの研究を行ってきました。過去には、UIをData Accessレイヤー（LinQTOSQL DBML）に直接接続するBLLを除外しました。しかし、これは私が今（または過去にさえ）働いている場所（または多分）であるとは思いません。

私の質問は、私のアプリケーションのほとんどで、私が本当にしているのは、linqtosqldatasource/gridviewを使用してデータコンテキストに接続してすべての更新/編集などを処理することだけで、BLLがどのように役立ちますか。アプリケーションは、あるレベルで、必要なデータを取得するためにDAL/BLLの一意の変更を必要とし、同じDAL/BLLを使用して他のアプリに影響を与える可能性があります。これはDAL/BLLの再利用ですか、これを行う正しい方法ですか、それとも何かが足りませんか？

たとえば、構築されるさまざまなWebアプリケーションのセキュリティクラスを構築する必要があるときにBLLが入っていると思います。しかし、LinqtosqldataSourceを使用するとき、なぜそれをBLLに接続するのを気にするのでしょうか？

ダル

• linqtosql dbml datacontext。
• linqtosqlを使用すると、このデザインの使用方法が変更されますか？

bll

• 会社が使用するさまざまなWebサイトのセキュリティ。
• クエリDAL return what（？）linqtosqldatsource。を使用する場合、さまざまな結果セットを処理する関数（これがBLLでどのように機能するかは本当にわかりません。質問が不明であれば申し訳ありません）

ui

• BLLのみを参照しますか？

Answer 1

DALとBLLは、しばしば微妙なもので分離されていますが、重要な違いがあります。ビジネスの論理。卑劣なように聞こえますが、違いは非常にうまくいき、アーキテクチャに大きな影響を与える可能性があるため、さらに説明しましょう。

LINQ2SQLを使用して、フレームワークは非常にシンプルなオブジェクトを生成し、それぞれが1つのテーブルで1つのレコードを表します。これらのオブジェクトはDTOです。それらは、フィールドのみを持つPoco（プレーンオルオブジェクト）クラスです。 LINQ2SQLフレームワークは、これらのオブジェクトをDBデータからインスタンス化して水分補給する方法を知っており、同様に、含まれるデータをSQLDMLに消化し、DBレコードを作成または更新できます。ただし、さまざまなオブジェクトのフィールド間の関係を管理する規則はほとんどないかまったくないかは、このレベルで知られています。

実際のドメインモデルはこれよりも賢くなければなりません。少なくとも、Subtotalという名前の注文オブジェクト上のプロパティがすべてのオーダーラインのすべての拡張コストの合計に等しく、同様に、拡張コストがユニットプライスと量の積である必要があることを知るのに十分なほど賢い。多くの現代のプログラムでは、少なくともこの程度まで、ドメインはBLLの一部を形成します。 LINQ2SQLによって作成されたオブジェクトは、特にサブテルまたは拡張コストを持続していない場合、これらすべてを知る必要はないはずです。 Linq2SQL DTOSに依存している場合、基本的に、既知のアンチパターンである貧血ドメインモデルと呼ばれるものに自分自身を結び付けました。ドメインオブジェクトが少なくとも内部的に一貫性を保つことができない場合、ドメインオブジェクトで動作するオブジェクトは、そのように保つために信頼される必要があり、それらすべてのオブジェクトが必要ではないルールを知るように要求します。

UIはドメインについて知っている必要があります。または、それを好む場合は、読み取りワイトの目的でドメインからデータを取得するための抽象化された方法を知っている必要があります（一般に、ドメインレイヤーおよび/またはLINQ2SQLで動作するコントローラーと呼ばれるオブジェクトにカプセル化されています）。 UIは、中程度のサイズ以上のプログラムでDBについて知る必要はありません。ドメインオブジェクトは、DALのオブジェクトへの参照で自分自身を水分補給することができます。または、水分補給を行うために作成するDALのカスタムオブジェクトによって生成され、コントローラーに与えられます。接続されたADOモデルとGridViewsとの相互作用は賞賛に値しますが、抽象化は許可されていません。ドメインとUIの間にWebサービスレイヤーを挿入して、倉庫のデータを使用したモバイルアプリにUIを配置できるようにしたいとします。 linq2sqlから直接オブジェクトを取得できなくなるため、UIを再構築する必要があります。 Webサービスから入手できます。 LINQ2SQLと話し合ったコントローラーレイヤーがある場合は、そのレイヤーをWebサービスに通信したコントローラーに置き換えることができます。わずかな違いのように聞こえます。あなたは常に何かを変えなければなりません。ただし、モバイルアプリとデスクトップアプリでまったく同じUIを使用しているため、2つのレイヤーがデータが異なる方法を取得するという理由だけで、そのレイヤーでの変更は2回作成する必要はありません。

Answer 2

これは、私が1年間カタログアプリを熟考してきたという素晴らしい質問です。私にとって特定のインスタンスは、パターンに役立つかもしれません。

ショッピングカートの内容を表示するページがあります。 「初期」では、このページには、注文番号が与えられたSQLストアドプロシージャの結果がカート内のアイテムをリストしたグリッドが入力されました。

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

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

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

うまくいけばそれは助けになりますか？