3層アーキテクチャ

Question

3 層アーキテクチャについていくつか質問があります。

1. 3 層アーキテクチャでアプリケーションを正しく実装するにはどうすればよいでしょうか?
2. これらの層間で通信するにはどうすればよいでしょうか?
3. データ層は DBMS と完全に同等ですか?(ストアド プロシージャを使用した場合はどうですか、またオブジェクト リレーショナル マッピング フレームワークを使用した場合はどうですか?)

ご回答をお待ちしております。ありがとう。

---

追伸：私が一般的な質問をしていることを理解してください。わかりました ？大規模なアプリケーションを正しく設計する方法を尋ねています。最善の方法は何ですか?あまり長い答えは期待していません。

Answer 1

これらは幅広い答えです。私はあなたにいくつかのポインターを与えるために最善を尽くします。

1. 「正しく」はやや主観的な用語です。一般的に言えば、私の意見では、最も重要なことは、レイヤーを独自のモジュール（たとえば、独自のDLL）に保持し、インターフェイスをモジュールに出入りさせることです。各レイヤーのインターフェイスを使用することにより、定義を実装から分離し、レイヤーを互いにさらに切り離すことができます。レイヤーに単一のエントリポイントがあり、インターフェイスに基づいている場合、必要に応じていくつかの基礎となる実装を行うことができます。もう一方の方向では、インターフェイスをコールバックとして使用する場合、レイヤークライアント（つまり、他のレイヤー）は、レイヤー間の適切なフローを取得するためにインターフェイスを実装する必要があります。

2. これは、レイヤー自体の実装方法に依存します。上記のようにレイヤーを設計すると、単にインターフェイスを使用してレイヤーに移動し、それから出ます。別の解決策は、イベントディスパッチャーを使用して非同期にすることです。レイヤーは単にイベントを発射し、別のレイヤーがこのイベントを聞いて行動します。それはすべて、プロジェクトの特定の要件に依存します。

3. いいえ、データレイヤーは、DBMSと相互作用するアプリケーション内のレイヤーです。 ORMを使用することはデータレイヤーを実装するための単なる方法です。一方、ストアドプロシージャの使用は、さまざまな理由で、ロジックの一部をアプリケーションからDBMS自体に移動する方法です。

いくつかの答えを受け取ると思います。それらすべてを考慮に入れ、ネット上で読書をして、好きなものを見つけるまで少し実験する必要があります。

Answer 2

1. 3つの層は、プレゼンテーション、ビジネスロジック、データです。懸念事項を混ぜないようにしてください。 UIは、ビジネスロジックなどを含めるべきではありません。

2. ティアは、その下の層についてのみ知っておく必要があります。 exのために。 UIはビジネスロジックとのみ通信する必要があり、データレイヤーについて何も知らないはずです。これを常に達成するために コンクリートの実装ではなく、インターフェイスへのコード. 。使用する 依存関係インジェクション モジュールをゆるく結合したままにします。

3. これは、どのように実装するかによって異なります。皮切りに ヤグニ 主要な。実際に必要な場合にのみ、ORMのようなものを最初から使用して使用するために、できるだけシンプルなものを保持します。

Answer 3

このトピックは、必要な深さでこの質問に適切に答えるには広すぎます。そうは言った：

1. 重要なアイテムは、各レイヤーが「下」のレイヤーのみを知っているように、レイヤー間の依存関係を適切に制限することです。たとえば、ビジネスレイヤーはプレゼンテーションレイヤーについて知りません。

2. 3層アーキテクチャは、レイヤーが互いにどのように通信するかについて処方箋を作成しません。ビジネス（ティア）機能は、プレゼンテーションレイヤーによって消費されるWebサービスとして頻繁に公開されます。

3. データ層は、データベースに完全に等しくはありません。データストア（ORMなど）と対話するには、常にいくつかのコードが必要です。このコードは、カップリングを最小限に抑えるために独自のモジュールにある必要があります。

Answer 4

これは多くの要因に依存します。データ アクセス レイヤー (DAL) にリポジトリ パターンを使用することを検討します。理想的には、これはエンティティ フレームワーク 4 や nhibernate のようなオブジェクト リレーショナル マッパー (ORM) と組み合わせて使用​​されます。次に、ビジネス ルールとサービスを含む別のドメイン層を作成します。ドメイン層は、UI と DAL 間のリクエストを処理します。UI には、Web フォームまたは MVC アプローチのオプションがあります。どちらも 3 層内で引き続き機能しますが、MVC から懸念事項をより適切に分離できます。これは、単体テストを行う場合に適しています。上記に関する良いリンクをいくつか紹介します。

http://daveswersky.com/2010/05/26/entity-framework-4-then-and-now/

http://channel9.msdn.com/blogs/matthijs/aspnet-mvc-2-basics-introduction-by-scott-hanselman

http://www.asp.net/mvc/tutorials/mvc-music-store-part-1

Answer 5

3つのティアアーキテクチャは、ステップバイステップの指導ではなく概念です。シンプルで孤立したままにしてください。データストレージと取得を使用している場合は、データレイヤーに入れてください。ロジックがある場合は、ロジック/中間層に配置します。テーマ/スキン、ビュー、ウィジェットプレースホルダーは、プレゼンテーションレイヤーになります。

他のコードを研究します。開始するのに適した場所があります モノレール.

他の人が何をしているのかを知るほど、たくさんのドキュメントを読むことができます。

とりわけ、それを楽しんでください。あなたが圧倒されたり、物事が複雑になっているように感じたりする場合は、一歩下がって、間違った場所にあるものを見つけてください。

Answer 6

3層アーキテクチャにアプリケーションを実装する最良の方法は、MVCを使用する言語のフレームワークを使用することです。 PHPには、Codeigniterをお勧めします http://codeigniter.com/

通常、何が起こるかは、OOPに従う場合、3つのレベルの間にオブジェクトを通過させることです。まあ、ほとんど2つ。コントロールはリクエストを取得し、モデル（DB）を要求し、見返りにオブジェクトを取得し、そのプロパティと方法を使用してビューを表示します。

CIのいくつかのチュートリアルに従ってください。 MVCで何が起こっているのかという考えが得られます。

Answer 7

3つのティアアーキテクチャには、プレゼンテーションレイヤー、ビジネスロジックレイヤー、データアクセスレイヤーの3つのレイヤーがあります。これら3つとは別に、ビジネスオブジェクトレイヤーを使用して、オブジェクトをデータベースにマッピングできるプロパティクラスを実装したり、エンティティフレームワークを使用したりできます。

プレゼンテーションレイヤー： これは、ユーザーがアクティビティを実行するアプリケーションの最上位層です。ユーザーがフォームに記入する必要があるアプリケーションの例を見てみましょう。このフォームは、プレゼンテーションレイヤーに他なりません。 Windowsアプリケーションでは、Windowsフォームはプレゼンテーションレイヤーであり、WebアプリケーションではWebフォームがプレゼンテーションレイヤーに属します。基本的に、ユーザーの入力検証とルール処理はこのレイヤーで行われます。

ビジネスレイヤー： これはプレゼンテーションレイヤーの上にあります。名前が示すように、ほとんどの事業運営はここで実行されます。たとえば、フォームデータを収集した後、カスタムビジネスルールでそれらを検証したいと考えています。基本的に、このレイヤーでクラスとビジネスエンティティを定義します。

データアクセスレイヤー： ビジネスロジックレイヤーの上には、データアクセスレイヤーがあります。ビジネスレイヤーがデータベースに接続し、CRUD操作を実行するのに役立つメソッドが含まれています。通常、すべてのデータベース関連コードとものは、データアクセスレイヤーに属します。時には、人々はプラットフォームに依存しないデータアクセスレイヤーを使用して、さまざまなデータベースベンダーからデータを取得します。

詳細 - https://www.c-sharpcorner.com/uploadfile/dacca2/understand-3-tier-architecture-in-charp-net/