Web 層が DAL に直接アクセスすることを許可しますか?

https://stackoverflow.com/questions/796656

18-09-2019
|

質問

私は、ここで少し現実を和らげた、認識されている「ベストプラクティス」に興味があります。

Web アプリケーションでは、Web 層が DAL に直接アクセスできるようにしますか、それとも最初に BLL を経由する必要がありますか?

ここで特に話しているのは、単純なクエリなど、実際には「ビジネスロジック」が関与していないシナリオです。「姓が「Atwood」の顧客をすべて取得します。」何らかのロジックがあるシナリオは絶対に BLL を通過するので、それを呼び出しましょうもー.

あなたがいる間 できた このメソッドを BLL オブジェクト内にカプセル化しますが、多くの場合、署名が DLL オブジェクトの署名とまったく同じであり、コードがおそらく DLL にクエリを委任する 1 ライナーと同じくらい単純である場合、これはやや無意味に思えます。

前者 (BLL オブジェクトを使用する) を選択する場合、これらのオブジェクトを何と呼びますか?(DLL にクエリ層を提供する以上のことはしないと仮定します)。ヘルパー？クエリプロバイダー?

考えてください。

よろしく

マーティ

解決

私の意見では、そうすべきです いつも BLL を使用します (ビジネスロジック層) Web 層と DAL の間 (データアクセス層).

より「単純な」クエリの一部については、BLL が DAL を厳密に模倣することを私は高く評価しています (例:すべての国を取得する、すべての製品タイプを取得するなど)、ただし正直に言うと、あなたの例でも次のようになります。

（すべての顧客を「Atwood」の姓でフェッチします）

ここには「ビジネスロジック」が表現されています。つまり、データレコードが姓によってフィルタリングされることを望むということです。

プロジェクトの開始時から BLL を実装すると、必要に応じて検証や追加の「ロジック」を挿入することが非常に簡単になります (プロジェクトが商用アプリケーションの場合、その必要性はほとんどなくなります) 確かに プロジェクトの開始時に存在しなかったとしても、最終的には発生します)。次のような追加ロジックを追加します。

今年10000ドル以上を費やしたすべての顧客を取得する

または

「Atwood」の姓を持つお客様が1000ドル以上のアイテムを購入できるようにしないでください

このロジックを Web 層にバールで組み込むよりも、真の BLL が関与すると、非常に簡単になります。

上記の種類のクエリでは、ほぼ確実に、この機能を実装するために特別に定義された関係を使用して結合する必要がある複数のエンティティとデータベーステーブルについて話していることに留意してください。DAL を直接操作してこれを実現しようとすると、複数のエンティティやクラスを扱うことになるため、面倒になります。ここで BLL を使用すると、Web 層のコードが大幅に簡素化されます。カプセル化するこれらのエンティティ関係は、大幅に簡素化されたインターフェイスの背後にあります。

これ "関心事の分離ユーザーインターフェイスを変更する必要が生じた場合、その重要性はますます高まります。

これまで少なくとも 2 回、私は Web サイトのユーザーインターフェイスを備えた商用 Web アプリケーションに取り組んできましたが、最終的には (ソフトウェア製品内での統合の強化を求めるクライアントから生じるビジネスニーズのため) ウェブサービス Web サイトとまったく同じ機能を提供するインターフェイス。

Web 層内にビジネスロジックを埋め込んでいた場合、Web サービスを実装するときにそのロジックを複製して書き直す必要がありました。実際のところ、すべてのビジネスロジックが BLL クラス内にカプセル化されていることを確認しました。つまり、一連の Web サービスインターフェイスメソッド呼び出しを設計し、これらを BLL クラスのメソッド呼び出しに対して接続するだけで済みました (実際には、ファサードデザインパターン Web サービス API を簡素化するために必要な場所にあります)。

結局のところ、そうする理由は思い当たりませんない DAL と Web 層の間に BLL 層を含めます。

最も簡単なのは、BLL が DAL をよく「模倣」する場合、確かにコードと機能が重複しているように見えますが、入力が少し増える一方で、実装が比較的簡単になります。

より複雑な場合 (重要なビジネスロジックが最初から存在する場合など)、懸念事項を分離すると、繰り返しを減らすことができます ( ドライ原則）同時に、将来および継続的なメンテナンスを大幅に簡素化します。

もちろん、これはすべて「手動」で行うことを前提としています。必要に応じて、DAL/BLL/UI レイヤーを大幅に簡素化できます。 ORM たくさんあります！(すなわち、 LINQ-to-SQL/エンティティ, サブソニック, NHibernate 等。）

他のヒント

私はここのほとんどの投稿に同意しません。

私はデータ層を Web 層と呼んでいます。Web/UI層の間に何もない場合、「念のため」というレイヤーを作成するポイントはありません。それは事前に最適化されています。もったいないですよ。ビジネスレイヤーが「私を救った」という時間を思い出せません。それがしたのは、より多くの作業、複製、より高いメンテナンスを作成することだけでした。私はビジネスレイヤー --> データレイヤーをサブスクライブして、レイヤー間でエンティティを渡すことに何年も費やしました。私はいつも、何も行わないパススルーメソッドを作成するのは汚いと感じていました。

紹介されてからはドメイン駆動設計 (Eric Evans 著), 、意味のあることをやります。UI とデータレイヤーの間に何もない場合は、UI でデータレイヤーを呼び出します。

将来の変更に備えて、すべてのデータ層クラスをインターフェイスでラップします。UI ではインターフェイスを参照し、依存関係注入を使用して実装を管理します。これらの変更を行った後は、まるで新鮮な空気が吹き込まれたような気分になりました。データ層と UI の間に何かを挿入する必要がある場合は、サービスを作成します。

もう一つ私がやったことは、プロジェクトの数を減らすことです。以前は、データレイヤー、ビジネスロジック、ビジネスエンティティ、およびある種の UI プロジェクトのプロジェクトを作成していましたが、これは大変な作業でした。

私には 2 つのプロジェクトがあります。コアプロジェクト (エンティティ、ビジネスロジック、データ層) と UI プロジェクト (Web、Web サービスなど)

詳細については、次の人物を参照することをお勧めします。

あなたはBLLオブジェクト（一体何が、これらはとにかくですか？ドメインは誰オブジェクト？）とサービスを区別する必要があります。あなたのドメインオブジェクトは、データアクセス層とは何の関係もないはずです。限りWeb層が行くように、それはちょうどそれが自由に使用することができ、他のサービスと同様に（IRepositoryと思う）あなたのリポジトリを扱うことができます。

だから、一番下の行は、次のとおりです。はい、Web層は、直接それが財産にカプセル化し、標準サービス・レイヤーサービスとして表され提供される。

DALを使用することができます

オンの場合でも、BLL 内の 1 行で DLL への同様の呼び出しを行うと、抽象化により次のことが可能になります。 ビジネスロジックを追加する 他のレイヤーに影響を与えることなく、そのレイヤーに追加されます。今はそんなことは起こりそうにないかもしれませんが、あなたの後にアプリケーションをサポートしなければならない人は、変更が起こったときにこのようなパターンを使ってくれたことに感謝するでしょう。

命名に関しては、NameChange というコアオブジェクトがあり、次に名前変更オブジェクトを受け入れる人物である BLL オブジェクトがあり、次に Person と呼ばれる DAL/Entity オブジェクトがあります。ビジネスパーソンオブジェクトは BLL 名前空間内にあり、DAL/エンティティパーソンオブジェクトは DB 名前空間内にあります (最初に DAL を構築していたら、DAL を選択していたでしょう)。

我々は、Web層からDALをカプセル化コントローラクラス[層]この層を指します。コントローラ層は、またはそれはプレゼンテーション層からDALを分離し、[ある程度]独立し、それらを維持するのに役立ちますない、いかなるビジネスロジックを持っていない可能性があります。

私たちは、しかし、私たちのプロジェクトは、我々、アクセスのためのファサードパターンを使用する傾向があってきました上のそれを使用するかなりのですが、私はそれは小さなプロジェクトでやり過ぎ証明するかもしれないと思う。

基本的には：

UI - > BusFacade - >ビジネスロジック - > DalFacade - > DataAccessLayer

ファサードは、エントリーの単一ポイントは、多くの方法を持っているとして、あなたの命名規則を標準化するためにUIからの素敵な/きれいなアプローチになり、そして軍ます。

BusFacade.GetCmsSiteMap()
BusFacade.GetProductGroup()

etc.etcます。

あなたが頻繁に認証を必要とするBLL飛ばしているDALにプレゼンテーション層から直接移動することは可能であろうが...

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow