17

私はいくつかの Web アプリケーションで MVC のかなりまともな表現だと思っていたものを実装しましたが、crackoverflow に参加して以来、おそらく私の最初の定義は少し単純化されていたことがわかりました。 Web アプリケーションのデータ アクセス層とモデルまたはドメイン層。

コンテキストとして、私は現在、オブジェクトが表すテーブル内の単一のレコードに対して CRUD 関数を実装するデータ アクセス オブジェクトと、オブジェクトを返す get() 関数を使用して、条件を満たすすべてのオブジェクトを反復処理できるようにします。 get() 関数の基準。

これらのデータ アクセス オブジェクトは、ビジネス ロジックを含むコントローラー スクリプトから直接参照されます。

問題があれば、私は PHP と MySQL で作業していますが、他の言語でコーディングできる提案に興味があります。

更新:より具体的な例として、電子メール アドレス、アクティブな状態、ユーザー名、パスワード、所属する会社などの情報を保持する user (ここでの規則は単一のテーブル名です) というテーブルがあります。この基本的なオブジェクトはコードでは次のようになります。

class User implements DataAccessObject
{
     protected $user_id;
     protected $email;
     protected $username;
     protected $password;
     protected $company_id;
     protected $active // Bool that holds either a 0 or 1

     public function __construct ( $user_id ) // Uses Primary Key to know which record to construct
     {
          $sql = //Sql to get this information from the database.

          // Code necessary to assign member variables their values from the query.
     }

     public function insert(){}
     public function update(){}
     public function delete(){}
     public static function get($filters, $orderVals, $limit){}

     // An object such as user might also contain the following function definition
     public static function login($username, $password){}
}

DAO レイヤーとモデル レイヤーを単純化して、実際のタイプの機能 (ユーザーのログインなど) とデータ アクセス機能の両方を組み合わせたように思えます。

4

2 に答える 2

30

モデルクラスは、実世界のエンティティの優れたクリーンで忠実度の高いモデルとして独立しています。それがビジネスのドメインであれば、顧客、計画、製品、支払いなど、あらゆる種類のものになる可能性があります。アプリケーションはこれらのクラスで動作します。アプリケーションは、ドメイン オブジェクトの実際の処理のモデルであるという考え方です。アプリケーションには、人々が実際に行う動詞のように見えるメソッド関数を含めることができ、それらのメソッド関数の実装は、現実世界のオブジェクトの実際の記述のように見えます。

重要: これは (理想的には) ほとんどの技術的な考慮事項とは無関係です。これは、定義できるドメイン オブジェクトの最も純粋なモデルです。[はい、外部キー ルックアップの問題があります。モデル オブジェクトが、実際のオブジェクトではなく外部キーのみを指定して他のオブジェクトを見つけられるように、モデル オブジェクトにいくつかのデータ アクセス コンポーネントを認識させる必要があります。優れた ORM レイヤーは、このナビゲーションの問題を処理します。]

SQL でいっぱいのモデルは、適切なモデルではありません。現実の世界も SQL でいっぱいではありません。請求書は、いくつかの名前、住所、品目、出荷日、およびそのようなものが含まれるドキュメントです。

アクセスクラスは永続ストレージを処理します。これには通常、モデル オブジェクトをリレーショナル データベース テーブルにマッピングすることが含まれます。SQL 指向のデータ アクセス レイヤーは、リレーショナル データベースからモデルを再構築し、モデルをリレーショナル データベースに永続化します。YAML データ アクセス レイヤーは、モデルから YAML ファイルを読み書きします。

オブジェクト リレーショナル マッピング (ORM) 設計パターンを使用して、SQL の世界とモデルを明確に分離することがあります。場合によっては、データ アクセス オブジェクト (DAO) が、SQL とモデルの間のこの分離を処理します。ORM または DAO オブジェクトは、SQL でいっぱいにパックできます。

実際、データベース製品を変更する場合、唯一の変更は DAO または ORM です。モデルは、SQL、YAML、JSON、XML、またはその他のシリアル化手法から独立しているため、変更されることはありません。

DAO がモデル オブジェクトを作成して永続化する場合、MVC のモデル部分が適切に実装されていると思います。ORM パッケージを見て、最先端のアイデアをさらに得ることができます。私自身、 iBatisのファンです。

しかし、それは MVC の世界観全体の 1/3 にすぎません。そしてもちろん、純粋主義者は、MVC はデスクトップのみ、または smalltalk のみ、または MVC の一般的な Web 実装とは異なると言うでしょう。

于 2008-10-13T15:40:50.283 に答える
8

それは、より高度な抽象化の問題です。解決しようとしているビジネス上の問題について考える場合、データベース オブジェクトやより詳細なレベルではなく、そのビジネスの概念 (エンティティ、関係、プロセスなど) の観点から考えてください。特定のデータベース システム (例: MySQL) の内部の用語。このようにして、実装に使用する特定のテクノロジーに依存せずに、ドメイン (つまり、ビジネスとそのルール) をモデル化できます。

言い換えれば、「データ アクセス レイヤー」について話すときは、テーブル、行、データ型、またはこれらのデータにアクセスする方法 (たとえば、アクティブ レコード パターンを使用して) について話しますが、ドメインについて話すときは、ビジネス オブジェクト、ビジネス ルール、ビジネス プロセスについて話します。

ちなみに、MVC パターンを使用する場合は、ビジネス ロジックをコントローラーではなくモデル (ドメイン) レベル (前述のとおり) にカプセル化する必要があります。つまり、これらのルールをトリガーするだけです。

于 2008-10-13T15:43:01.807 に答える