リンクの相互作用と分離。 パート1
nリンクシステムの論理リンクは、相互作用し、隣接リンクによってのみ影響を受けるように設計する必要があります。 この制限はしばしば違反され、システムに悪影響を及ぼします。 この記事では、これが通常起こる理由、結果について説明し、レイヤーの分離に大きな注意を払う必要がある理由を説明します。
この記事は基本に専念し、それらの詳細な説明です。 詳細な例を含む次の記事は、それに基づいています。 この記事は、「 ビジネスロジックはどこにありますか？ 」 で説明した原則に基づいています。 「（「 おい、私のビジネスロジックはどこですか？ 」）。
物理リンクが相互にどのように配置されているかを考えてみましょう。
この例では、3リンクシステムを示します。 すべてのリンクは、隣接するレイヤーとのみ相互作用できます。
クライアントリンクからストレージリンクへの直接アクセスは禁止されています。 彼らは隣人ではありません。 ほとんどの開発者は、そのような飛躍を試みません。 ただし、この記事では、論理層でこのルールに違反することすら気づかない開発者について説明します。
層と層という用語は、しばしば同じ意味で使用されます。 リンクという用語を使用する場合、物理リンクを意味します。 「レイヤー」を使用する場合、論理レイヤーのみを意味します。 リンク内にはレイヤーが存在するため、リンクはレイヤーで構成されます。
レイヤーはリンクに固定されていません。 実際には、次の2つの図に示すように、ビジネス層は特定の実装に応じてリンク間を移動できます。 すべてのレイヤーがモバイルではありませんが、多くのレイヤーがあります。 実装は、ネットワークトポロジおよびその他の要因に依存します。
デモンストレーションでは、nリンクシステムにはさらに多くのレイヤーを含めることができるという事実にもかかわらず、3つのレイヤーを使用します。 各層は、隣接層のみと通信し、隣接層のみに依存する必要があります。
リンクに配置すると、1対1に一致する写真が表示されます。
したがって、論理層を想像します。 インターフェイスを介した接続のみが予想される場合、一致は完了します。 論理層では、インターフェイスへの接続だけでなく、インターフェイスの設計、相互接続、およびその他の制限にも注意を払う必要があります。 これらはすべて、注意を払っていない、または気づいていない論理層のゴーストです。
これはかなり一般的な実装です。 プレゼンテーション層にはストレージ層との物理的な接続はありませんが、両方とも相互に依存して開発されたため、現実には妥協ソリューションを必要とする制限が導入されました。
レイヤー間の接続をよりよく見るためにレイヤーを配置すると、状況はより明確になります。 透明な多層システムの代わりに、典型的な循環システムを取得します。
トップレベルのみをデモンストレーションしました。 ただし、各レイヤーには独自の追加のサブレイヤーがあります。
一般的な論理接続を追加すると、「隣人へのアクセスのみ」というルールに明確に違反していることに気付くでしょう。
場合によっては、論理レベルだけでなくルールに違反しないが、物理的な接触が発生し、隣人を飛び越えます。
このようなシステムは非常に壊れやすく、アップグレード、拡張、デバッグが困難です。 任意のレイヤーで作業するには、開発者は「おとぎ話の開発者」でなければなりません。 彼はシステム全体について悪いことも良いこともすべて知っていなければならないという意味で。
リンクを削除し、ダイアグラム上のレイヤーを異なる方法で配置すると、何が起こったのかを簡単に確認できます。 明らかに、単にレイヤーをジャンプするだけでなく、ある種のWebが作成されました。
このテンプレートを使用する場合、データストレージレイヤーが最初に設計され、次にプレゼンテーションレイヤーがそれに添付されます。 これらの作業の最後に、ビジネスロジックのレイヤーがデータレイヤーに付加されます。 プレゼンテーション層は既にデータ層に基づいて設計されています。 これにより、プレゼンテーションレイヤーで外部の制限が発生し、ビジネスロジックレイヤーでデータを変更する機能が制限されます。 多くの場合、ビジネスロジックレイヤーから返されるデータは、SQLクエリまたはストアドプロシージャを使用して実行できる簡単な変更に限定されます。
このパターンは非常に典型的です、なぜなら これは、開発における従来のクライアント/サーバーアプローチおよび既存のデータベースを中心に設計されたシステムに非常に似ています。 プレゼンテーションレイヤーはデータストレージレイヤーに基づいて設計されているため、プレゼンテーションレイヤーは実際のデータ構造を表示することが多く、直感的でないインターフェイスを備えています。
非常に多くの場合、プレゼンテーション層とデータ層のフィードバックがあります。 プレゼンテーション層で受け入れ可能な形式で一部のデータを受信できない場合、フィードバックが表示されます。 次に、開発者はプレゼンテーション層を改善するためにデータストレージ層を変更する必要がありますが、そのような変更はデータストレージ層にとって望ましくない場合があります。 このような変更は異質であり、環境の制限がなければ、それらは必要ありません。 このような変更は、多くの場合、データベースの適切な構築を混乱させるか、単に妨害し、データの不必要な複製と非正規化につながります。
このアプローチでは、データストレージレイヤーはプレゼンテーションレイヤーに基づいて設計されます。 ビジネスロジックレイヤーの実装は通常、単純なSQLクエリで構成され、実際には変換も分離も行いません。 データベースは設計が不十分であり、パフォーマンスの問題があります。 もともとは、データベースの標準化やその他の一般的な要件を考慮せずに、プレゼンテーション層にデータを便利に提供するために作成されました。
分離アプローチを使用する場合、プレゼンテーションレイヤーとデータストレージレイヤーは、互いに独立して、多くの場合並列に設計されます。 これらの2つの層を設計した後、ビジネスロジック層のアーキテクチャを開発し、プレゼンテーション層またはデータ層に影響を与えることなく、必要なすべての変換を提供することが彼の仕事です。
なぜなら プレゼンテーションレイヤーとデータレイヤーは完全に独立しました。いずれも変更でき、必要に応じてビジネスロジックレイヤーの変更を伴います。 物理的に分離された2つのレイヤーのいずれかの変更は、他のレイヤーに直接影響しません。 これにより、システム全体を全面的に変更または更新することなく、プレゼンテーションレイヤーまたはデータストレージレイヤーの構造をすばやく変更し、ユーザーのニーズに迅速に対応できます。
この記事を2つの部分に分けたことを一般に謝罪したいと思います。 しかし、最近、大きなテキストはHabréに受け入れられなくなりました。 誰かがこの不幸に対処する方法を教えてくれた場合：私は感謝します。
継続
この記事は基本に専念し、それらの詳細な説明です。 詳細な例を含む次の記事は、それに基づいています。 この記事は、「 ビジネスロジックはどこにありますか？ 」 で説明した原則に基づいています。 「（「 おい、私のビジネスロジックはどこですか？ 」）。
物理リンク
物理リンクが相互にどのように配置されているかを考えてみましょう。
この例では、3リンクシステムを示します。 すべてのリンクは、隣接するレイヤーとのみ相互作用できます。
クライアントリンクからストレージリンクへの直接アクセスは禁止されています。 彼らは隣人ではありません。 ほとんどの開発者は、そのような飛躍を試みません。 ただし、この記事では、論理層でこのルールに違反することすら気づかない開発者について説明します。
レイヤーリンク
層と層という用語は、しばしば同じ意味で使用されます。 リンクという用語を使用する場合、物理リンクを意味します。 「レイヤー」を使用する場合、論理レイヤーのみを意味します。 リンク内にはレイヤーが存在するため、リンクはレイヤーで構成されます。
レイヤーはリンクに固定されていません。 実際には、次の2つの図に示すように、ビジネス層は特定の実装に応じてリンク間を移動できます。 すべてのレイヤーがモバイルではありませんが、多くのレイヤーがあります。 実装は、ネットワークトポロジおよびその他の要因に依存します。
ストレージリンクのビジネスロジックのレイヤー
クライアントリンクのビジネスロジックのレイヤー
論理肢
デモンストレーションでは、nリンクシステムにはさらに多くのレイヤーを含めることができるという事実にもかかわらず、3つのレイヤーを使用します。 各層は、隣接層のみと通信し、隣接層のみに依存する必要があります。
リンクに配置すると、1対1に一致する写真が表示されます。
したがって、論理層を想像します。 インターフェイスを介した接続のみが予想される場合、一致は完了します。 論理層では、インターフェイスへの接続だけでなく、インターフェイスの設計、相互接続、およびその他の制限にも注意を払う必要があります。 これらはすべて、注意を払っていない、または気づいていない論理層のゴーストです。
これはかなり一般的な実装です。 プレゼンテーション層にはストレージ層との物理的な接続はありませんが、両方とも相互に依存して開発されたため、現実には妥協ソリューションを必要とする制限が導入されました。
レイヤー間の接続をよりよく見るためにレイヤーを配置すると、状況はより明確になります。 透明な多層システムの代わりに、典型的な循環システムを取得します。
トップレベルのみをデモンストレーションしました。 ただし、各レイヤーには独自の追加のサブレイヤーがあります。
一般的な論理接続を追加すると、「隣人へのアクセスのみ」というルールに明確に違反していることに気付くでしょう。
場合によっては、論理レベルだけでなくルールに違反しないが、物理的な接触が発生し、隣人を飛び越えます。
このようなシステムは非常に壊れやすく、アップグレード、拡張、デバッグが困難です。 任意のレイヤーで作業するには、開発者は「おとぎ話の開発者」でなければなりません。 彼はシステム全体について悪いことも良いこともすべて知っていなければならないという意味で。
リンクを削除し、ダイアグラム上のレイヤーを異なる方法で配置すると、何が起こったのかを簡単に確認できます。 明らかに、単にレイヤーをジャンプするだけでなく、ある種のWebが作成されました。
設計パターン
データ層からの設計パターン
このテンプレートを使用する場合、データストレージレイヤーが最初に設計され、次にプレゼンテーションレイヤーがそれに添付されます。 これらの作業の最後に、ビジネスロジックのレイヤーがデータレイヤーに付加されます。 プレゼンテーション層は既にデータ層に基づいて設計されています。 これにより、プレゼンテーションレイヤーで外部の制限が発生し、ビジネスロジックレイヤーでデータを変更する機能が制限されます。 多くの場合、ビジネスロジックレイヤーから返されるデータは、SQLクエリまたはストアドプロシージャを使用して実行できる簡単な変更に限定されます。
このパターンは非常に典型的です、なぜなら これは、開発における従来のクライアント/サーバーアプローチおよび既存のデータベースを中心に設計されたシステムに非常に似ています。 プレゼンテーションレイヤーはデータストレージレイヤーに基づいて設計されているため、プレゼンテーションレイヤーは実際のデータ構造を表示することが多く、直感的でないインターフェイスを備えています。
非常に多くの場合、プレゼンテーション層とデータ層のフィードバックがあります。 プレゼンテーション層で受け入れ可能な形式で一部のデータを受信できない場合、フィードバックが表示されます。 次に、開発者はプレゼンテーション層を改善するためにデータストレージ層を変更する必要がありますが、そのような変更はデータストレージ層にとって望ましくない場合があります。 このような変更は異質であり、環境の制限がなければ、それらは必要ありません。 このような変更は、多くの場合、データベースの適切な構築を混乱させるか、単に妨害し、データの不必要な複製と非正規化につながります。
プレゼンテーションレイヤーのデザインパターン
このアプローチでは、データストレージレイヤーはプレゼンテーションレイヤーに基づいて設計されます。 ビジネスロジックレイヤーの実装は通常、単純なSQLクエリで構成され、実際には変換も分離も行いません。 データベースは設計が不十分であり、パフォーマンスの問題があります。 もともとは、データベースの標準化やその他の一般的な要件を考慮せずに、プレゼンテーション層にデータを便利に提供するために作成されました。
孤立したデザインテンプレート
分離アプローチを使用する場合、プレゼンテーションレイヤーとデータストレージレイヤーは、互いに独立して、多くの場合並列に設計されます。 これらの2つの層を設計した後、ビジネスロジック層のアーキテクチャを開発し、プレゼンテーション層またはデータ層に影響を与えることなく、必要なすべての変換を提供することが彼の仕事です。
なぜなら プレゼンテーションレイヤーとデータレイヤーは完全に独立しました。いずれも変更でき、必要に応じてビジネスロジックレイヤーの変更を伴います。 物理的に分離された2つのレイヤーのいずれかの変更は、他のレイヤーに直接影響しません。 これにより、システム全体を全面的に変更または更新することなく、プレゼンテーションレイヤーまたはデータストレージレイヤーの構造をすばやく変更し、ユーザーのニーズに迅速に対応できます。
| データストレージレイヤーからの設計 | ビューレイヤーからデザインする | 孤立したデザイン | |
| データベース |
|
|
|
| ビジネス要件 |
|
|
|
| 拡張性 |
|
|
|
この記事を2つの部分に分けたことを一般に謝罪したいと思います。 しかし、最近、大きなテキストはHabréに受け入れられなくなりました。 誰かがこの不幸に対処する方法を教えてくれた場合：私は感謝します。
継続
All Articles