1. MVC の問題点
ビジネス ロジックがそれほど複雑ではないシナリオでは、MVC が引き続き有効です。しかし、フロントエンド MVVM (Model-View-View-Model) 開発モデルの台頭、特に のようなフロントエンド フレームワークの人気の高まりにより、サーバー側のレンダリングが必要なくなったため、サーバー側の設計パターンの使用はますます少なくなりVueました。ReactMVCView
さらに、MVC実際には、階層化された設計パターンはまだ粗いものです。
Model階層化されたコードはデータを維持するだけでなく、ビジネス ロジックもカプセル化します。ビジネス ロジックがますます複雑になるにつれて、この層の機能ロジックはますます肥大化して保守が困難になります。- チーム管理の場合、
Controllerと のModel責任の境界は比較的曖昧であり、開発者が優れたコードを書くための要件は比較的高くなります。
2、3 層アーキテクチャ (3 層アーキテクチャ)
MVC3 層アーキテクチャと呼ばれることもありますが、3 層アーキテクチャには特別な用語 (3 層アーキテクチャ) があります。
2.1 プレゼンテーション層 — UI
User Interface3層構造の最上位に位置し、B/S内の主にWEBページなどユーザーと直接接する部分であり、APIインターフェースとなることもあります。プレゼンテーション層の主な機能はシステムデータの入出力を実現することであり、この過程でデータは論理的な判断演算を必要とせずにデータ処理のためにBLLシステムに送信され、処理結果は処理後にプレゼンテーション層にフィードバックされます。言い換えれば、プレゼンテーション層は、ユーザー インターフェイス/API インターフェイス機能を実装し、ユーザーのニーズについて通信およびフィードバックを提供し、ユーザー エクスペリエンスを確保するためにデバッグに BLL またはモデルを使用します。
2.2 ビジネスロジック層 - BLL
Business Logic Layer特定の課題に対して論理的な判断を行い、操作を実行する機能を持ち、プレゼンテーション層のUIからユーザーの指示を受け取った後、データアクセス層のDALに接続します ビジネスロジック層は、3層アーキテクチャのプレゼンテーション層とデータ層の中間に位置します。
2.3 データアクセス層 — DAL
Data Access Layerデータの追加、削除、変更、確認などの操作を実現し、操作結果をビジネスロジック層のBLLにフィードバックするデータベースの主要な制御システムです。実際の運用プロセスでは、データ アクセス層には論理的な判断能力はありませんが、コード記述の厳密性を実現し、コード読み取りレベルを向上させるために、一般的なソフトウェア開発者は、データ アクセス層 DAL のデータ処理機能を確保するために、この層に一般的なデータ機能をカプセル化 (たとえば、ORM コンポーネントを通じて) 実装します。
2.4 モデル定義層 — モデル
モデル定義は、Entity主にデータベース テーブルのオブジェクトをマッピングするために使用されるエンティティ オブジェクトによって表現されることも多く、情報システム ソフトウェアの実際の開発プロセスでは、ソフトウェア開発におけるさまざまなシステム機能の制御と操作を支援するオブジェクト エンティティの形式でリレーショナル データベース テーブルを表現するオブジェクト インスタンスを確立する必要があります。エンティティクラスライブラリを確立し、各構造層のパラメータ伝達を実現し、コードの可読性を向上させます。本質的に、エンティティ クラス ライブラリは主にプレゼンテーション層、ビジネス ロジック層、データ アクセス層に機能し、3 つの層間でデータ パラメータを送信してデータ表現の簡素化を強化します。
ここでの Model と MVC 設計パターンの Model は同じ名前ですが、その違いは大きく、責任がまったく異なることに注意してください。