3 層アーキテクチャについていくつか質問があります。
あなたの答えを聞くのを楽しみにしています。ありがとう。
PS: 私が一般的な質問をしていることを理解しないでください。わかった ？大規模なアプリケーションを正しく設計する方法を尋ねています。最善の方法は何ですか?. 長い答えを期待していません。
これらは大まかな答えです。私はあなたにいくつかの指針を与えるために最善を尽くします.
「正しく」はやや主観的な用語です。一般的に言えば、私の意見では、最も重要なことは、レイヤーを独自のモジュール (独自の DLL など) に保持し、モジュールに出入りするインターフェイスを持つことです。各層でインターフェイスを使用することにより、定義を実装から分離し、層を互いにさらに切り離すことができます。レイヤーへの単一のエントリ ポイントがあり、それがインターフェイスに基づいている場合、必要に応じて複数の基になる実装を使用できます。逆に、インターフェイスをコールバックとして使用する場合、レイヤー クライアント (つまり、他のレイヤー) は、レイヤー間の適切なフローを得るためにインターフェイスを実装するだけで済みます。
それは、レイヤー自体をどのように実装するかによって異なります。上で提案したようにレイヤーを設計する場合、インターフェイスを使用してレイヤーに出入りするだけです。もう 1 つの解決策は、イベント ディスパッチャーを使用して非同期にすることです。レイヤーは単純にイベントを発生させ、別のレイヤーがこのイベントをリッスンしてそれに基づいて動作します。それはすべて、プロジェクトの特定の要件に依存します。
いいえ、データ層は、DBMS と対話するアプリケーション内の層です。ORM の使用は単にデータ レイヤーを実装するための方法ですが、ストアド プロシージャの使用は、さまざまな理由から、ロジックの一部をアプリケーションから DBMS 自体に移動するための方法です。
いくつかの答えが返ってくると思います。それらすべてを考慮に入れ、ネット上でいくつかの情報を読み、気に入ったものが見つかるまで少し実験する必要があります。
このトピックは広すぎて、必要な深さでこの質問に適切に答えることができません。それは言った：
重要な項目は、各レイヤーが「下」のレイヤーのみを認識できるように、レイヤー間の依存関係を適切に制限することです。たとえば、ビジネス層はプレゼンテーション層について知りません。
3 層アーキテクチャでは、レイヤーが相互に通信する方法について規定はありません。ビジネス (層) 機能は、プレゼンテーション層によって消費される Web サービスとして公開されることがよくあります。
データ層はデータベースと完全に同じではありません。データ ストア (ORM など) とやり取りするには、常に何らかのコードが必要です。結合を最小限に抑えるために、このコードは独自のモジュールに含める必要があります。
3 つの層は、プレゼンテーション、ビジネス ロジック、およびデータです。懸念事項を混同しないように注意してください。UI にはビジネス ロジックなどを含めないでください。
どの層も、その下の層についてのみ知っている必要があります。たとえば。UI はビジネス ロジックとのみ通信する必要があり、データ レイヤーについては何も認識しない必要があります。これを実現するには、具体的な実装ではなく、常にインターフェイスにコードを記述します。依存性注入を使用して、モジュールを疎結合に保ちます。
これは、どのように実装するかによって異なります。YAGNIプリンシパルから始めます。最初はできる限りシンプルにして、ORM などは本当に必要な場合にのみ使用してください。
3 層アーキテクチャでアプリケーションを実装する最善の方法は、MVC を使用する言語のフレームワークを使用することです。PHP の場合、CodeIgniter http://codeigniter.com/をお勧めします
通常、OOP に従うと、3 つのレベル間でオブジェクトが受け渡されます。まあ、ほとんど2つです。コントロールはリクエストを取得し、モデル (DB) に問い合わせてオブジェクトを取得し、そのプロパティとメソッドを使用してビューを表示します。
Ci のいくつかのチュートリアルに従います。MVC で何が起こっているかがわかります。
これは多くの要因に依存します。データ アクセス レイヤー (DAL) にリポジトリ パターンを使用することを検討します。これは、エンティティ フレームワーク 4 や nhibernate などのオブジェクト リレーショナル マッパー (ORM) と組み合わせて使用するのが理想的です。次に、ビジネス ルールとサービスを含む別のドメイン レイヤーを作成します。ドメイン層は、UI と You 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
3 層アーキテクチャは概念であり、段階的な説明ではありません。シンプルで独立したものにしてください。データの保存と取得を行う場合は、データ レイヤーに配置します。必要なロジックがある場合は、ロジック/中間層に配置します。テーマ/スキン、ビュー、ウィジェット プレースホルダーはプレゼンテーション レイヤーに入ります。
他のコードを研究します。開始するのに適した場所はmonoRailです。
他の人が何をしているかを知れば知るほど、たくさんのドキュメントを読んでください。
何よりも、楽しんでください。圧倒されたり、物事が複雑になってきているように感じたりした場合は、一歩下がって、何が間違っているのかを見つけてください。
3 層アーキテクチャには、プレゼンテーション層、ビジネス ロジック層、データ アクセス層の 3 つの層があります。これら 3 つとは別に、ビジネス オブジェクト レイヤーを使用して、オブジェクトをデータベースにマップできるプロパティ クラスを実装したり、エンティティ フレームワークを使用したりできます。
プレゼンテーション層 : これは、ユーザーがアクティビティを実行するアプリケーションの最上位層です。ユーザーがフォームに入力する必要があるアプリケーションの例を見てみましょう。このフォームはプレゼンテーション層に他なりません。Windows アプリケーションでは、Windows フォームはプレゼンテーション レイヤーであり、Web アプリケーションでは、Web フォームはプレゼンテーション レイヤーに属します。基本的に、ユーザーの入力検証とルール処理はこのレイヤーで行われます。
ビジネス層 : これはプレゼンテーション層の上にあります。その名の通り、ほとんどの業務がここで行われます。たとえば、フォーム データを収集した後、カスタム ビジネス ルールでデータを検証したいとします。基本的に、このレイヤーでクラスとビジネス エンティティを定義します。
データ アクセス レイヤー : ビジネス ロジック レイヤーの上にデータ アクセス レイヤーがあります。これには、ビジネス層がデータベースに接続して CRUD 操作を実行するのに役立つメソッドが含まれています。通常、データベースに関連するすべてのコードやものは、データ アクセス層に属します。プラットフォームに依存しないデータ アクセス レイヤーを使用して、さまざまなデータベース ベンダーからデータを取得することがあります。
詳細 - https://www.c-sharpcorner.com/UploadFile/dacca2/understand-3-tier-architecture-in-C-Sharp-net/