1

ここ数日、私は DAL/BLL/UI アプローチを使用して多くの調査を行ってきましたが、それが私のプロジェクトにどのように適用されるかについて明確に理解していませんでした。以前は、UI をデータ アクセス層 (LINQtoSQL dbml) に直接接続する BLL を省略していました。しかし、これは私が現在 (または過去に) 働いている場所では良い考えではないと思います。なぜなら、私たちは多くの異なるアプリケーションを持っており、それらが構築されているのと同じ DAL/BLL を使用したいからです。

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

ビルドするさまざまな Web アプリケーションのセキュリティ クラスなどをビルドする必要がある場合に、BLL が役立つと思います。しかし、Linqtosqldatasource を使用する場合、わざわざ BLL に接続する必要があるのでしょうか。

ダル

  • LinqToSQL dbml データ コンテキスト。
  • LinqToSQL を使用すると、この設計の使用方法が変わりますか?

BLL

  • 企業が利用する各種Webサイトのセキュリティ。
  • Query DAL return what(?) when using LinqToSQLDatSource., さまざまな結果セットを処理する関数 (これが BLL でどのように機能するかは本当にわかりません。質問が不明な場合は申し訳ありません)

UI

  • BLL のみを参照しますか?
4

2 に答える 2

2

DAL と BLL は、しばしば微妙ではあるが重要な違いによって分離されます。ビジネスの論理。ばかばかしいほど単純に聞こえますが、さらに説明させてください。なぜなら、区別は非常に細かいものでありながら、アーキテクチャに大きな影響を与える可能性があるからです。

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

実際のドメイン モデルはこれよりもスマートである必要があります。少なくとも、SubTotal という名前の Order オブジェクトのプロパティが、すべての OrderLine のすべての ExtendedCost の合計と等しくなければならず、同様に、ExtendedCost が UnitPrice と Quantity の積であることを知っているほど賢いです。多くの最新のプログラムでは、少なくともこの程度では、ドメインは BLL の一部を形成します。Linq2SQL によって作成されたオブジェクトは、特に SubTotal または ExtendedCost を保持していない場合は、おそらくこれらすべてを認識する必要はありません。Linq2SQL DTO に依存している場合は、基本的に、既知のアンチパターンである Anemic Domain Model と呼ばれるものに縛られています。ドメイン オブジェクトが少なくとも内部的に一貫性を保つことができない場合、そのドメイン オブジェクトと連携するすべてのオブジェクトは、それを維持するために信頼されなければなりません。

UI はドメインについて認識している必要があります。または、必要に応じて、読み取り/書き込みの目的でドメインからデータを取得するための抽象化された方法を認識している必要があります (通常、ドメイン層や Linq2SQL と連携するコントローラーと呼ばれるオブジェクトにカプセル化されています)。中規模以上のサイズのプログラムでは、UI は DB について知る必要はありません。ドメイン オブジェクトは、DAL 内のオブジェクトへの参照を使用して自身をハイドレートするか、ハイドレーションを実行するために作成した DAL 内のカスタム オブジェクトによって生成され、コントローラーに渡されます。接続された ADO モデルと GridViews との相互運用性は素晴らしいものですが、抽象化はできません。ドメインと UI の間に Web サービス レイヤーを挿入して、ウェアハウス内のデータを操作するモバイル アプリに UI を配置できるようにしたいとします。UIを再構築する必要があります Linq2SQL からオブジェクトを直接取得できなくなったためです。それらは Web サービスから取得します。Linq2SQL と通信するコントローラー レイヤーがある場合、そのレイヤーを Web サービスと通信するコントローラーに置き換えることができます。小さな違いのように思えます。常に何かを変更する必要があります。しかし、今ではモバイル アプリとデスクトップ アプリでまったく同じ UI を使用しているため、2 つのレイヤーが異なる方法でデータを取得するという理由だけで、そのレイヤーでの変更を 2 回行う必要はありません。

于 2010-12-08T21:06:27.647 に答える
0

これは、私がカタログ アプリで 1 年間考え続けてきた素晴らしい質問です。私にとっての特定の例は、パターンであなたを助けるかもしれません.

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

これで、「行」オブジェクトのコレクションを含む「カート」BLL オブジェクトができました。グリッドは同じですが、データ ソースはカートの行です。

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

次に、カートはリポジトリを使用して行をロードします。各行には、データがどこから来たのかわからないまま、それ自体を操作するロジックがあります。

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

于 2010-12-08T21:09:48.367 に答える