ASP.NET の三層アーキテクチャ(DAL、BLL、UI)

クズども · 掲載地 2015/05/07 10:53:35

BLLはビジネスロジックレイヤーです

DALはデータアクセス層のことです

ASP.NET の三層アーキテクチャ(DAL、BLL、UI)

グラフィックスは三層構造を表します。ウェブはUSLレイヤーです

ウェブ –> BLL –> DAL
|          |       |
|          V |
+–>モデル<—+

1. 三層アーキテクチャ
1. プレゼンテーション層(USL):主にWEB手法を表しますが、WINFORMモードとしても表現できます。論理レイヤーがかなり堅牢で確立されていれば、パフォーマンスレイヤーの定義や変更に関わらず完璧に機能します。
2. ビジネスロジック層(BLL):主に特定の問題に対して、データ層の動作およびデータビジネスの論理処理とも理解できます。データ層がビルディングブロックなら、論理レイヤーがビルディングブロックとなります。
3. データアクセス層(DAL):これは主に元のデータ(データベースやテキストファイル、その他のデータの保存形態の形)の操作層であり、元のデータではなく、つまりデータの操作であり、特にビジネスロジック層やプレゼンテーション層ではありません

      データサービスの提供。

2. 具体的な区別
1. プレゼンテーション層:主にユーザーの要求を受け入れ、データを返すため、クライアントにアプリケーションへのアクセスを提供します。
2. ビジネスロジック層:主にデータ層の動作、すなわちいくつかのデータ層操作の組み合わせを担当します。
3. データアクセス層:主にデータ層が論理処理を含んでいるかどうかによります。実際、その機能は主にデータファイル上の様々な操作を完了するものであり、他の操作を気にする必要はありません。

3. 概要
三層構造は厳密な階層的アプローチであり、データアクセス層(DAL)はビジネスロジック層(BLL)のみがアクセス可能で、ビジネスロジック層にはプレゼンテーション層(USL)のみがアクセス可能です。一部の三層構造は、ファクトリーやモデルのような他の層も追加しており、これらは実際にはこれら三層に基づく拡張および応用です。

単純な3層プログラムは一般的に、DAL BLLウェブモデルの複数のプロジェクトを含み、それらの相互参照は以下の通りです
1) WEB参照 BLL、モデル
2) BLLの参照 DAL、モデル
3) DAL参照モデル
4) モデルに引用がない

三層アーキテクチャに関して言えば、パフォーマンス層(UI)、ビジネスロジック層(BLL)、データアクセス層(DAL)であることは誰もが知っていますが、それぞれの層を細分化する方法は多様です。しかし、具体的なコードをどう書くか、そしてそれらのファイルがどのレイヤーにカウントされるかは曖昧です。以下は、三層アーキテクチャプロジェクトの実践を目指す簡単な例です。この例には、ユーザー管理という一つの機能しかありません。

   まず、空の解を作成し、以下のアイテムやファイルを追加します
   1. ASP.NET Web アプリケーションプロジェクトを追加し、UIと名付け、新しいWebフォームファイルUser.aspx(User.aspx.csを含む)を作成します。
   2. ClassLibraryプロジェクトを追加し、BLLと名付け、新しいClassファイルを作成するUserBLL.cs
   3. ClassLibraryプロジェクトを追加し、DALと名付け、新しいClassファイルUserDAL.csを作成します。 SQLHelperの参照を追加してください。 (これはMicrosoftのデータアクセスクラスで、すべてのデータアクセスコードを直接書くこともできます。) 私は通常、自分が書いたDataAccessHelperクラスを使っています。
   4. ClassLibraryプロジェクトを追加し、Modelと名付けて新しいClassタイプファイルを作成しますUserModel.cs
   5. ClassLibraryプロジェクトを追加し、IDALと名付け、新しいインターフェースファイルを作成するIUserDAL.cs
   6. ClassLibraryプロジェクトを追加し、ClassFactoryと名付けました
   これはPetshopの例と何ら変わらず、私もPetshopを通じて三層アーキテクチャを学んでいるので、よりシンプルであることはご存知の通りです。ただし、友人の中にはこれらのプロジェクトのレベルや関係性について曖昧な意見があるかもしれませんが、以下は一つ一つ説明します。
   1. User.aspxとUser.aspx.cs
   両方の文書(およびファイルが属する項目、および以下は繰り返し表示されません)はプレゼンテーション層の一部です。 User.aspx表示ページなので理解しやすいです。 User.aspx.cs、数えるべきではなくビジネスロジック層に含まれるべきだと考える人もいます。レイヤーリングをしなければ、ビジネスロジックの処理やデータベースの運用User.aspx.cs問題ありませんが、レイヤーリングを行う場合は、これはやるべきではありません。階層構造では、User.aspx.cs表示に関連するコンテンツのみを扱い、それ以外の内容は扱うべきではありません。
   例えば、ユーザーを表示する機能をリストの形で実装すると、情報抽出作業はBLLが行い、UI(この場合はUser.aspx.cs)がBLLを呼び出してUserInfoを取得した後、リスト表示を実現するためにUser.aspxのデータ制御にコードでバインドされます。このプロセスUser.aspx.cs UIには役割を担わず、データの伝達にのみ使われます。また、実際のコーディングの多くがこのように実装されているため、User.aspx.cs UIとしてカウントすべきではなく、論理処理のためにBLLに統合すべきだと考える人もいます。さらに調べると、各ユーザーの前に性別を鮮やかに表現するアイコンを追加する新たな要件が提案され、18歳未満の場合は子供アイコンで表現されました。この要件の実現がUser.aspx.csの回転であり、この場合User.aspx.cs実際に使われています。
   2、NewBLL.cs
   以下の方法を加えてください:
   public IList GetUsers(): すべてのユーザー情報のリストを返します
   public UserInfo GetUser(int UserId): 指定されたユーザーの詳細を返します
   public bool AddUser(UserInfo User):追加されたユーザー情報
   public bool ChangeUser(UserInfo User):ユーザー情報を更新します
   public void RemoveUser(int UserId): ユーザー情報を削除する
   このファイルはビジネスロジック層に属し、ビジネスロジックに関連する操作を処理するために専用です。多くの人は、このレイヤーの用途はパフォーマンス層からデータ層への転送だけだと思っているかもしれません。確かにそのようなケースは多くありますが、これはプロジェクトが比較的単純であるか、プロジェクト自体とビジネスの関係が密接に統合されていない(現在の人気MISのように)場合に限られます。そのため、ビジネス層は関与せず、単にフォワーディングの役割を果たすだけです。しかし、これはビジネス層が不要だという意味ではなく、プロジェクトが拡大したり、ビジネス関係が増えても、ビジネス層はその役割を反映していきます。
   ここで最も起こりやすい誤りは、データ操作コードをビジネスロジック層に割り当て、データベースをデータアクセス層に割り当ててしまうことです。
   例えば、友人の中にはBLLレイヤーが意味がないと感じている人もいますが、DALデータをアップロードして処理せずにUIに転送するだけです。この例を見てください
   BLL層
   SelectUser(UserInfo userInfo)は、届いたユーザー名やメールアドレスに基づいてユーザー情報を取得します。
   IsExist(UserInfo userInfo)は指定されたユーザー名やメールアドレスが存在するかどうかを判断します。
   さらに、DALはBLLコールに対応するメソッドも提供します
   SelectUser(UserInfo userInfo)
   IsExist(UserInfo userInfo)
   この点で、BLLは伝達の役割のみを果たしています。
   でも、もしそうなら:
   BLL IsExist(Userinfo ユーザー情報)
   {
   UerInfo ユーザー = DAL. SelectUser(User);
   return (userInfo.Id != null);
   }
   この場合、DALはIsExist()メソッドを実装する必要がなく、BLLには論理処理コードが存在します。
   3、UserModel.cs
   エンティティ、このものは、層分けが簡単ではないと思うかもしれません。私を含めて、私はこう理解していました:UI?àModel?àBLL?àModel?àDALであり、このモデルは層間のデータ伝達の橋渡し役を果たすと考えられています。しかしここでは、単純なことではなく複雑さを考えます。
   モデルとは何か? たいしたことではありません！三層構造では不要です。実はオブジェクト指向プログラミングで最も基本的なもの、すなわちクラスです。テーブルはクラスであり、ニュースもクラスであり、int、string、doublieなどもクラスであり、単なるクラスです。
   このようにして、三層アーキテクチャにおけるモデルの位置は、intやstringなどの変数の状態と同じであり、他の目的はなく、データ保存のみに使われますが、複雑なデータを保存します。したがって、プロジェクトのオブジェクトが非常に単純であれば、モデルなしで複数のパラメータを直接渡すことで3層アーキテクチャを作成できます。
   では、なぜモデルが必要なのか、そしてその利点は何でしょうか? 以下は、ここに挿入された質問を考えるときに思い浮かぶことです。
   モデルは各層でのパラメータ伝達においてより大きな役割を果たせるでしょうか?
   レイヤー間でパラメータを渡す際には、以下のことができます。
   AddUser(userId, userName, userPassword,...,)
   また、次のようなものもあります:
   AddUser(userInfo)
   この2つの方法のうち、どちらが優れているのでしょうか? 一見すると、後者の方がずっと良いはずです。
   通常の変数型(int、string、guid、double)を持つレイヤー間でパラメータを渡すのはいつ、Modelでは何を渡すか? 以下の方法:
   SelectUser(int UserId)
   SelectUserByName(文字列ユーザー名)
   SelectUserByName(文字列ユーザー名、文字列パスワード)
   SelectUserByEmail(文字列メール)
   SelectUserByEmail(文字列メール、文字列パスワード)
   要約すると次の通りです。
   SelectUser(userId)
   SelectUser(ユーザー)
   ここではユーザーモデルオブジェクトを用いて、ユーザー名、パスワード、メールの4つの組み合わせモードを含みます。 UserIdもユーザーにマージできますが、プロジェクト内の他のBLLはidパラメータ付きインターフェースを実装しているため、この項目も保持されます。
   ユーザー情報は渡されるので、どう対処するかは順番通りで、特定のコードを決める必要があります。
   ここではこの順番で処理されます
   まず、ユーザー名とパスワードの両方があるか確認し、次にメールアドレスとパスワードの両方を持っているか、ユーザー名があるか、最後にメールアドレスがあるか確認します。順番に処理します。
   このようにして、将来的に新しいコンテンツ(会員カード(番号)が追加された場合、インターフェースを変更する必要はなく、DALコードに番号のサポートを追加し、前景に会員カード内容のパフォーマンスと処理を追加するだけで済みます。
   4、UserDAL.cs
   public IList SelectUsers(): すべてのユーザー情報のリストを返します
   public UserInfo SelectUser(int UserId):指定されたユーザーの信頼できる情報を返します
   public bool InsertUser(UserInfo User):追加されたユーザー情報
   public bool UpdateUser(UserInfo User): ユーザー情報を更新します
   パブリック・ヴォイド DeleteUser(int UserId): ユーザー情報を削除する
   多くの人が理解できないのはデータアクセス層、つまりどの部分がデータアクセス層とみなされるのかということです。データベースがデータアクセス層だと考える人もいますが、定義が明確ではありません。DALはデータアクセス層であり、データストレージ層ではないため、データベースはこの層にはなりません。 SQLHelperの役割は、繰り返しコーディングを減らし、コーディング効率を向上させることです。ですから、効率を重視したり、データベース以外のデータソースを使うことに慣れているなら、SQLHelperを自由に捨てることができるのに、三層構造のレイヤーになるにはどうすればいいのでしょうか。
   定義は次の通りです:データソース操作に関連するコードは、データアクセス層に属するデータアクセス層に配置されるべきです
   5、IUserDAL
   データアクセスレイヤーインターフェースも不要ですが、PetshopはClassFactoryと連携しているため、複数のデータソースをサポートするかどうかに関わらずこの2つの機能を実装するプロジェクトもあります。中にはClassFactoryをビルドせずにIDALだけをビルドし、さらに「IUserDAL iUserDal = new UserDAL()」というものもあります。意味がわからない。これは完全に虎であり、犬に反対するわけではありません。
   多くの人は誤解しています。つまり、BLLとDALの橋渡し役を考え、BLLはIDALをIDAL経由で呼びます。しかし実際には、たとえこう書いても「IUserDAL iUserDal = ClassFacotry.CreateUserDAL(); 「iUserDal.SelectUsers()」を実行する場合、実際にはIUserDALインスタンスではなくUserDALインスタンスが実行されるため、第3層におけるIDALの位置はDALレベルに関連しています。
   上記の導入を通じて、三層アーキテクチャの階層が基本的に説明されています。実際、三層構造が標準かどうかを判断する方法があります。つまり、三層のいずれかを完全に置き換えても他の二層には影響が出ず、そのような構造は基本的に三層標準を満たしています(ただし実装はより難しい^_^です)。例えば、プロジェクトをB/SからC/Sに変更した場合(またはその逆)、BLLとDALはUI以外は変更する必要はありません。あるいはSQLServerをOracleに変更したり、SQLServerDALをOracleDALに置き換えるだけで、他の操作は不要です。もともとは記事に特定のコードを追加しようと思っていましたが、必要だとは思いません。必要だと感じるなら追加します。
   まとめ:レイヤーが自分にとって無意味だからとか、実装が特に簡単だからとか、放棄したり、他の目的で使うからといって不要だと思わないでください。レイヤーが実行されている限り、層の数に関わらず、各レイヤーには明確な目的と機能の実現が必要であり、実際のプロセスに左右されて同じ種類のファイルが異なるレイヤーに配置されてはいけません。同じレイヤーが異なる機能を実装させないようにしましょう。

[ASP.NET] ASP.NET の三層アーキテクチャ(DAL、BLL、UI)

関連記事

閲覧したセクション