3層設計は、データベース駆動型アプリケーションの長年の標準的な設計哲学であり、失敗したことはありません。それを実践する人のために、あなたのレイヤーを説明してください。
多くの人がビジネス層とデータアクセス層を混乱させ、2.5層の設計のようになっていることがわかりました。
ストアドプロシージャを使用してデータ層をほぼ完全にデータベースに移動し、sproc呼び出しをビジネスオブジェクトにラップする非常に軽量なデータ層をコードに含めることを好みます。
どのようにアプローチしますか？
編集：3層とは何かを定義するだけの場合は、返信に時間を無駄にしないでください。特定の人がそれをどのように実装したかを探しています。ストアドプロシージャまたはORMを使用しましたか、DALとBLLの間の循環依存関係をどのように処理しましたか？このトピックには、言う以外にも多くの深みがあります
私はしばらくの間、主にWebアプリを実行しており、3層もフォローしています。
UI：純粋なASPXページ。ここで簡単な計算などを行うのはとても簡単なように思われるため、実際には、ビジネスレイヤーをここから押し下げるのは難しい場合があります。ただし、ページの背後にあるコードがパネルの表示/非表示、ユーザー入力の更新などを実行していることを確認するのに十分な訓練を受けています。
DAL：すべてのデータアクセス層のもの。利用可能なXSD/DataTable/TableAdapterクラスの使用を本当に楽しんでいます。また、ストアドプロシージャベースのCRUDメソッドを使用しているため、アダプタをストアドプロシージャに接続するのは簡単です。
BLL：ビジネスレイヤーは、ここにあるほとんどのアプリの3つのレイヤーの中で最も軽い傾向があります。これは、これらが主にCRUDタイプのアプリであり、いくつかのレポートが組み込まれているためです。
3層：
私は、データベースとの通信のすべてではないにしても、ほとんどをストアドプロシージャを使用して処理するという点で、3層設計をほぼ同じ方法で実践しています。私はクラスの設計に取り組み、複雑さを軽減し、変更の際の柔軟性を高めるために、各クラスに特定の目的があるようにします。
3層設計で遭遇する最大の問題の1つは、入力検証をどこに置くかです。多くの場合、UIレイヤーとビジネスレイヤーの両方で検証を複製して、ユーザーに迅速な検証チェックを提供し、データレイヤーに出入りするデータが有効であることを確認します。検証をどのように処理しますか？
補足として、n 層の階層化はプロセスの物理的な分離ではなく、論理的な階層化であることを忘れないでください。つまり、プレゼンテーション コードとは別のプロセス (または別のボックス) でビジネス ロジックを実行する必要はありません。重要なことは、コードをきれいに保つことです。
プレゼンテーション コードとビジネス ロジックを物理的に分離することは、たとえば Web サービスを使用してバックエンドに接続するなど、以前から宣伝されてきました。これが良いアイデアである場合もありますが、決して必要ではありませんが、アーキテクチャ、展開、設計、およびコスト パフォーマンスが大幅に複雑になります。
レイヤリングは非常にうまくいくと思います。 OSIモデルの層を見てください。 私はあなたが説明する3つの層を使用しましたが、そのアプローチは本当に役に立ちました。Model View Controllerの抽象化は、大規模なデスクトップアプリケーションで役立つことがよくあります。あなたは物事をますます小さく、より扱いやすい部分に分割し続けることができます。収穫逓減のポイントがあります。また、抽象化レイヤーを削除して、ハードウェアと直接通信したい場合もあります。これは、アプリケーションの目的によって異なります。
私が作成した新しい Web アプリケーションには、2.5 層の設計が最適であることがわかりました。通常、2 つのクラス ライブラリと 1 つの Web アプリケーションから始めます。
Company.Data(クラス ライブラリ)Company.Web(クラス ライブラリ) ( PageBase、カスタム コントロール、ヘルパー関数などを含む)Company.Web.WebApplication（ウェブアプリケーション）私が作成したアプリケーションでは、ストアド プロシージャのみを使用してデータにアクセスします。実際、CodeSmith テンプレートを作成して、すべてのストアド プロシージャ、データ、およびビジネス クラスを生成しました。
Company.Data
このアセンブリは、主にエンティティ データ クラスとコレクションで構成されます。たとえば、通常Settings、Web アプリケーションで呼び出されるテーブルがあります。Settingと呼ばれるクラスSettingCollectionが生成されます。
したがって、特定の設定をロードする必要がある場合は、これを行うことができます..
Dim setting As New Setting(1) 'pass in the id of the specific setting
setting.Value = "False" 'change the value
setting.Save() ' Call the save method to persist changes back to the database
または、新しい設定を作成するために、コンストラクターに値を渡さないだけです
Dim setting as New Setting()
setting.Name = "SmtpServer"
setting.Value = "localhost"
setting.Save()
アセンブリ内の私の名前空間はCompany.Data通常、次のようになります..
Company.Data.Entites
Company.Data.Collections
Company.Data.BusinessObjects
(この名前空間は、データにアクセスするためのカスタム メソッドを作成するために使用されます)
また、主キー、外部キー、および一意のインデックスに基づいてカスタム メソッドを生成します。
たとえば、設定テーブルの名前列には一意のインデックスがあります。呼び出される共有メソッド GetSettingByNameが自動的に生成され、これが設定オブジェクトを返します。このメソッドはCompany.Data.BusinessObjects名前空間にあります
エンティティ クラスとビジネス オブジェクト クラスの場合、2 つのファイルが生成されます。1 つは毎回生成され、1 つは編集可能で初回のみ生成されます。部分クラスを使用して、上書きせずにカスタム コードを追加できるようにします。
私にとって、この方法論は非常にうまく機能しています。Codesmith の生成により、数え切れないほどのコーディング時間を節約できます。テーブルに 5 つの新しい列を追加し、すべての新しいコードを数秒で再生成できます。ストアド プロシージャは削除され、再作成されます。
私のアプリケーションは 1 つのデータベースのみを使用し、それが Sql Server であるため、2.5 層の設計はうまく機能します。将来、access、oracle、mysql を使用する必要はありません。
約6層のデザインを使用しています。
ブラウザ側の Javascript など。これは純粋なビジュアル シュガーであり、ビジネス上の価値や処理はほとんどありません。ここでの入力検証はすべて冗長なチェックです。それらはバイパスされる可能性があるため、信頼していません。
サーバー側の HTML プレゼンテーション。これは部分的にビジネス ルール主導です。しかし、私たちが使用するテンプレート言語には処理がありません。
サーバー側のビュー関数、ビジネス ロジック、「コントロール」。ここで、ナビゲーション、検証、および「高レベル」のアプリケーション指向処理が行われます。ここで状態変化が発生します。計算、更新、削除などが行われます。これが処理です。これは、認証と承認が実施される場所です。
モデル定義 (ORM レイヤーを使用)。これがオブジェクトモデルです。これはリレーショナル モデルにマップされます。これには、モデル レベルのすべての処理がオブジェクト メソッドとして含まれます。ここでいくつかの計算が行われ、フィルタリング、カウント、順序付けがここで定義されます。これは、データの有用なビューです。
アクセス層 (ある種のデータベース接続)。データベース製品によって異なります。これは ORM レイヤーによって管理されるため、コーディングは一切行わず、構成のみを行います。
DB 内の永続ストレージ (ストアド プロシージャなし、トリガーなし)。
私たちはかつて、次の方法を使用してアプローチしました。-UIレイヤー（すべてのUIがある場所）-ビジネスレイヤー（すべてのビジネスロジックがある場所）-データレイヤー（すべてのDBアクセスがある場所）