19

私は「MVC を学ぶ」方法の始まりにいます。基本的に、オブジェクト指向プログラミングに大きな問題はありませんが、明確にする必要がある技術的な側面が 1 つあります。どうやら私の理論は十分ではないようです。

現在、KohanaPHP フレームワークのバージョン 3 を使用しています。

状況の例: ユーザーが記事を送信できる Web サイトを持っています。

だから私は次の構造を持っています：

classes/
    /controllers/
        article.php
    /models/
        articles.php

ここまでは順調ですね。Kohana_Model を拡張するモデルに問題はありませんが、ORM を使用している正しい方法のモデルを使用しているかどうかはわかりません。

基本的に、Kohana_Model を拡張するモデルを使用する場合、すべての論理演算をモデルに入れます。ORM を使用するモデルについても同じことを行う必要がありますか? ネット上の多くの例で、データベースからのユーザー入力/データに対して論理操作を実行しているコントローラーを見ましたが、これは私の意見では正しくありません。

データベースからいくつかの行を取得する必要があるとしましょう。そのため、モデルに適切なメソッドを作成してオブジェクトを返します。正しいと思いますね。

基本的に、ユーザー入力/データに対するすべての操作 (データベースからの選択、データベースへの挿入、検証) をモデルに入れました。それが私がMVCデザインパターンを理解する方法です。モデルはすべての「機械的」操作を処理する必要があり、コントローラーはモデル/ビュー間の「ブリッジ」にすぎず、「フロント」エンジンです。

それは正しいアプローチですか？

より高度なユーザーにとってはばかげた質問かもしれませんが、良いプラクティスだけを学びたいと思っています。誰かが明確にすることができれば、私は喜んでいます。

4

4 に答える 4

67

簡単に言えば、モデルはデータ (着信、発信、データベース、ファイルなど) に対するすべての操作を実行し、ビューはデータの表示を処理する必要があります。コントローラーは、必要なモデル メソッドを呼び出して、データをビューに渡す準備を整える必要があります。コントローラーはデータに変更を加えるべきではありませんが、必要なアクションが適切に行われるようにテストする必要があります。

これで問題が解決しない場合はお知らせください。

于 2011-01-11T10:15:40.943 に答える
2

私は KohanaPHP を使ったことはありませんが、「レールにインスパイアされた」フレームワークのように見えます。レールの世界では、一般的に、スリムなコントローラーとファットなモデルを使用することがベスト プラクティスと見なされています。

いくつかの背景は、jamis buck http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-modelによるこの古い記事、または Cakephp に関するこの記事http://gluei.com/blogで見つけることができます。 /view/cakephp-best-practices-fat-models-and-skinny-controllers

于 2011-01-11T10:14:16.663 に答える
1

データからロジックを分離するという考え方は、データにはロジックが含まれていないため、モデルでは実際にはデータのみをサニタイズする必要があります。

次の例を見てください。

public class Articles extends MasterModelLayer
{
    public function create($title,$text,$user_id = false)
    {
        if(!$user_id)
        {
             $user_id = get_guest_id();
        }
        //Insert
    }
}

モデルの正当なロジックのように見えますが、これからはアプリケーションでゲストが記事を投稿できるようにする必要があります。または、モデルに欠陥があり、モデルを編集する必要があります。これにより、サイトの他のアプリケーション/領域がフロアになります

次のシナリオを考えてみましょう。

2 つのサイトがあります

  • ComputerArticles.com
  • 料理記事.com

現在、これら 2 つのドメインは同じサーバーを指していますが、kohona の別のアプリケーションを指しています。モデル内にドメイン ロジックを配置しないことで、すべてのドメインで正確なサンプル モデルを使用できます。

モデル メソッドは次のようになります。

public class Articles extends MasterModelLayer
{
    public function create($title,$text,$user_id)
    {
        $this->compile("articles",array($title,$text,$user_id))->insert();
    }
}

また、ロジックはドメインに依存するため、コントローラー内にすべてのロジックを配置する必要があります。

モデルを API と考えてください。同じ API を使用する複数のサイトがありますが、ロジックは異なります。

お役に立てれば。

于 2011-01-11T10:33:58.647 に答える
0

用語の基本的な素人の定義は次のとおりです。 ビュー: ユーザーに表示される画面 コントローラー: リクエストを受け取り、誰がそれを処理するかを決定し、適切に委任するエンジン/フレームワーク。モデル: これは基本的に、この画面でアクションが実行された後に表示する画面を示します。（有向）グラフと考えてください。ノードから出てくるエッジはアクションであり、それらが接続するノードはそれらのアクションに基づく次の画面です。

したがって、モデルには基本的に、ユーザーが画面上で行うアクションとそのアクション ハンドラーが含まれます。コントローラーは、特定のユーザー アクションに対応するアクション ハンドラーを呼び出すだけで、アクション ハンドラーは受信した要求に対して適切な処理を実行します。

今あなたの質問。ビジネス ロジックはどこに行くのか? さて、それはアクションハンドラです。または、ビジネス層と呼ばれる場所で抽象化されます。とにかく、アクションハンドラー自体からトリガーされます。

したがって、技術的には、ビジネス ロジックは、それ自体がモデルの一部であるアクションの一部です。これは、次のように考えると理にかなっています。コントローラーはユーザー インタラクションを処理し、モデル (アクション + ビジネス) に基づいてビューを表示します。

** タイプミスが修正されました。

于 2011-01-11T10:34:20.253 に答える