3

私はMVCを使い始めたばかりですが、考えを切り替えることができれば、MVCは素晴らしい方法になると思われます。

私が遭遇したほとんどの資料は、モデル、ビュー、およびテーブルの間に1対1の関係があるようです。つまり、各モデルはテーブルを表し、CRUDに加えて、より複雑な関数を許可します。

アカウントの作成と更新を可能にするアカウントモデルがある場合はどうなりますか。

/ signupビューとコントローラーを使用してアカウントを作成（）したいのですが、/ members / accountビューとコントローラーを使用してpwの更新、変更などを行いたいと思います。

サインアップモデルを使用する方がよいでしょうか、それとも複数の場所から必要なモデルを使用するだけで大​​丈夫ですか？

また、アカウントには多くのユーザーがいる可能性がありますが、サインアップ時に最初のユーザーを作成したいとします。アカウントの設定とユーザーの作成をトランザクションとして実行したいと思います。アカウントモデルとユーザーモデルがあり、両方を使用する必要がありますか、それともアカウントのサインアップcreate（）関数でデフォルトユーザーを作成する必要がありますか？

私はCodeIgniterでPHPを使用しています

4

1 に答える 1

4

一般に、あなたがしたいことは、テーブルをモデルの下の追加の「レイヤー」と見なす可能性が最も高いです。MVC の概念は一般に、バッキング イシューの実装をあまり扱っていません。つまり、DB テーブル、フラット ファイル ストレージ、またはインメモリ データ表現を使用しているかどうかです。

私が提案したいのは、この問題を、テーブルとアプリケーションの間の相互作用を行う 1 つのレイヤーを持つことの 1 つとして見ることです。あなたの「データオブジェクト」レイヤー。これを純粋なシリアル化と考えてください。オブジェクト モデルを使用している場合、これが ORM レイヤーになります。

次に、「ビジネス ロジック」を定義する別のレイヤーが必要です。つまり、データとデータの相互作用です。これは、アカウントがユーザーとやり取りする方法などに関係しています。ここでのカプセル化は、基本的に高レベルのやり取りを処理します。このようにして、実装に依存する必要なく、ビジネス要件に最も適した抽象化を定義できます。たとえば、ユーザー アカウントを処理するために必要なすべてのことを実行する「UserAccount」モデルを定義できます。その抽象化で実行したいすべてのことを定義します。次に、その抽象化ができたら、それがモデルです。次に、そのモデルの内部動作で、永続化コードとの相互作用がどのように発生するかを定義できます。

このようにして、モデルの永続性と実装を実際の Modelインターフェイスから抽象化します。そのため、基礎となる実装を気にせずに、モデルがやりたいことを実行するようにモデルを定義できます。これには大きな利点があります。モデルの実行方法とは別に、モデルに実行させたいことを考えるプロセスは、非常に有益です。同様に、バッキング データ レイヤーが変更されても、モデルを変更する必要はありません。たとえば、フラットファイルでプロトタイプを作成できます。

于 2008-11-06T00:13:34.453 に答える