アプリケーションロジック、ビジネスロジック、モデル、コントローラー-アプリケーションの頭脳をどこに置くか？
モデル、ビュー、コントローラーに頭を回そうとしていますが、読むほど、矛盾する情報に出会うように感じます。一般的な目標は、これまで見てきた限りでは、ファットモデルとシンコントローラーを狙うことだと思いますが、それでも、どこに何を配置するかには少し困惑しています。私が取り組んでいるものから例を挙げられますか？
これは、私がPHP楽しみのために-一種のミニゲームです。時間指定されたタスクを旅程に追加し、タスクが完了したときに報酬を収集しています。このようなクラスが存在します：
class ItineraryEntry {
public $user_id;
public $task_id;
public $completion_time;
}
そして、このような別のクラス：
class Task {
public $task_id;
public $description;
public $duration; //in seconds
}
したがって、ユーザーインターフェースでは、ユーザーはタスクの説明を見て、「旅程に追加」のようなものをクリックします。ここで私が正しく理解している場合、コントローラーはその要求を取得して何かを行う必要があります。しかし...いくら？たとえば、タスクがいつ完了するかを把握する必要があります。単純にしておくと、それは単にtime（）+タスクの期間です。それでは、コントローラーはその計算を行ってからモデルに渡して検証しますか、それともモデルはそのすべてを処理するだけですか？そして、コントローラーは本当にデータの栄光のルーターに過ぎませんか？
次に、2番目の部分は、旅程のタスクが完了するとどうなるかです。したがって、ユーザーインターフェースから、完了時間が過去の場合、タスクは完了したと表示され、ユーザーは「報酬の申請」のようなものをクリックする必要があります。それは...わからない... XP（つまり、経験値）-ユーザーのアカウントで更新されるものです。また、XPの量は、タスクの難易度、必要な時間などに基づいて何らかの方法で計算されるとしましょう。
それで、私はその計算をどこに置くでしょうか？それはユーザーオブジェクトのモデルクラス内にありますか、それともすべてを把握してユーザーオブジェクトに送信するコントローラーがありますか？旅程エントリモデルのモデルは？そして、私がこれを具体的に尋ねる理由は、あらゆる種類のClaim Rewardsコードが少なくともいくつかのことを行う必要があるためです。
- 実際に報酬を請求し、ユーザーのアカウントを更新します
- 期限切れのタスクをデータベースからクリーンアップします（または完了したものにマークを付けます）。
そのため、ユーザーと旅程のエントリの両方と相互作用します。
少し具体的なガイダンスは本当に役に立ちます。私の知る必要があるような説明のすべてを読むことで、頭が痛くなり始めていますが、完全ではありません。よろしくお願いします！
MVCはさまざまなもののlotを意味する可能性があり、正しい答えはおそらく「私のフレームワークで機能するものや、私が使用または実行している他のすべてのものです。 」
これは、歴史を理解することが、人々がなぜ彼らが彼らのやり方で物事を行うのか、それが何を意味するのか、そしてアイデアが将来どのように進化するのかを理解するのに役立つトピックです。最後は重要です。人々が5年間でどのように物事を行うかを理解できれば、5年間で誰よりも「モダンな方法」で5年以上の経験を積むことができます。履歴の完全なバージョンについては、 http://c2.com/cgi/wiki?ModelViewControllerHistory を参照してください。
ここに要約があります。元々、MVCはインタラクティブアプリケーション用に登場しました。 （私はこれが流用のように見えることを知っていますが、これは問題になります。）すべての単一のインタラクティブコンポーネント-すべてのドロップダウンなどには、独自のモデル、ビュー、およびコントローラーがありました。 3つすべての仕事は明確に定義されていました。コントローラーは、発生する可能性のある一連のイベント（誰かがマウスをクリックした、キーを押した、別のコントローラーが何かを行うことを伝えるメッセージを渡した）を処理します。次に、ビューとモデルについて知っていました。ビューはそれ自体を描画する方法を知っていました（下にスクロールしたり、アイテム＃3を選択したりするように指示されました）。そして、モデルはビューにあるものを決定するデータを担当していました（たとえば、ドロップダウンのエントリのリスト）。非常に、非常に細かい。たくさんのコンポーネント。動的な相互作用がたくさん。
MVCはこの方法でインタラクティブアプリケーションに引き続き使用されます。
その後、ウェブが登場しました。プログラマが新しいドメインに移動するときに行う1つのことは、既存のパターンを引き継ぐことです。 MVCは実績のあるものでした。 Webのコンテキストでは、関心のある唯一のイベントは「要求ページX」です。ユーザーが自分の情報を編集できるページであるとします。それに関連付けられたデータモデルがあるでしょう。 「これらのフィールドを持つユーザーオブジェクト」を考えてください。景色が見えるでしょう。 「ユーザーを表示する方法のテンプレート」と考えてください。同じオブジェクトに対して異なるビューを設定することもできます-私があなたのホームページを見ると、あなたとは異なる情報を見ることが許されています。
ここまでは順調ですね。問題はどこだ？沢山あります。ここに短いリストがあります。
- 通常、動的なWebページの生成は、インタラクティブなアプリケーションでボタンのクリックを処理するよりもはるかに複雑です。したがって、3つのコンポーネントはそれぞれ、アプリケーションの場合よりも複雑な処理を実行しています。
- 何がどこに属しているかは、人々には不明確です。同じコードをモデル、ビュー、コントローラーに含めることができますが、どこにあるかが重要であることはすぐにはわかりません。しかし、ランダムなものは特にコントローラーに挿入するのが簡単な傾向があります。
- 複雑なWebページには、フォーム、サイドバー、広告など、データモデルを必要とする複数のものが含まれます。それをどのように表現しますか？
- Webサイトでは一般的に多くのビューがありますが、それらの間で一貫したビューを維持したいとします。これを可能にするために、プログラマーではないデザイナーにとって理にかなっているビューをどのように構成しますか？
- 時間の経過とともに、AJAXのようなトリックを備えた、よりリッチでより複雑なインタラクティブページに移行しています。これを、httpリクエストを処理するときに自然なページごとの考え方にどのように結び付けますか？
等々。
これらにはさまざまなトレードオフの可能な解決策がたくさんあります。一般に、フレームワークを使用し、フレームワークが期待する方法で問題を解決しようとすると、問題はうまく機能します。そうでなければ、まあ、物事は挑戦的になります。したがって、フレームワークで機能するものを実行するための上記の私のアドバイス。
しかし、一般的な原則があります。
コントローラーには複雑な作業があり、追加のロジックを簡単に挿入できるため、時間の経過に伴うコードの自然な進行は、すべてが既知のコントローラーに組み込まれることです。相互作用する単一のコードブロックは、適切にスケーリングされない傾向があります。したがって、コントローラから、コントローラから、キープできるすべてのものを保持する必要があります。 （一部のフレームワークは、コントローラーを再帰的に分割することにより、物事をさらに簡単にします！）
ほとんどの場合、ビジネスロジックはモデルに属しています。データベースとオブジェクトリレーショナルマッパーがある場合、単純なアプリケーションのモデルをデータベーステーブルのかなり単純なレイヤーとして簡単に構築できます。人気のデザインです。
ビューは通常、ある種のテンプレートシステムです。共通点の扱い方はテンプレートシステム次第です。使用しているシステムを理解し、その中で作業してみてください。
あなたは自認された初心者です。私は、フレームワークを選択し、そのフレームワークの推奨ベストプラクティスに従って（後で、フレームワークが最適ではないと判断した場合でも、フレームワークが予期するようなコードの編成は、予期せぬ驚きを最小限に抑える傾向がある）ことを強くお勧めします。より複雑なものに取り組む。私はこれを強く、強く、強くお勧めします-走る前に、あなたが歩くのが得意であることを確認してください。
しかし、歩きながら、この投稿に戻って、上記で示した問題点のリストを確認し、あなたの苦痛を打ったか、打たなかったか、そしてあなたが構築したものの中でそれらをどのように処理できるかを考えてください。このタイプの意図的な「どうすればいいですか？」内省は改善の重要な部分です。私が言ったように、これらは多くの異なるフレームワークで発生する既知の問題点であり、それらを処理するための最良の方法はまだ見つかっていないと思います。
どこに行くのか推測しなければならないとしたらどう思いますか。
私の信念は、Webページがよりインタラクティブになるにつれて、それらは既存のインタラクティブアプリケーションのようになりつつあるということです。 （最近、キーボードショートカットでgmailを使用しましたか？）それらがインタラクティブアプリケーションになるほど、インタラクティブアプリケーションで使用される方法でJavaScriptでMVCを使用することが理にかなっています。フロントエンドが複雑になればなるほど、生成するコードが配信されるのと同じように構造化されたコードによって配信されるHTMLを配信することが理にかなっています。
もしそうなら、私たちは（確かに私はすでにそうであると信じています）多くのコントローラー、多くのモデル、そして相互作用することができる多くのビューを持つフロントエンドWebページを見るべきです。これらは最終的にサーバーにプッシュバックされ、同様の粒度でページのこれらの部分が生成されることが期待されます（ただし、Xを有効にするJavaScriptライブラリが実際にページの適切な部分に読み込まれるように情報を渡す機能はあります）そのため）。
これは、このように構造化された独自のシステムを使用してきたためでもあると思います。興味深かった。多くのコントローラー、ビュー、モデルがありました。ただし、コントローラーは共通性を処理するためにいくつかのデータ継承を伴うデータ構造に変わり、ビューは単純なテンプレートになり、モデルはコントローラーからの情報によってパラメーター化されました。懸念事項が非常に離れていたため、3つを3つの異なる言語（Perlモデル、YAMLコントローラ、TTテンプレート）に置くことができました。バックエンドを完全に書き直すなどのことを行うことができました。フロントエンドのほとんどを変更せずに再利用できるようにしながら、Webサイト（文字どおり異なるページにアクセスし、異なる順序でアクセスされ、異なるサービスにアクセスしていました）。
その実装がそれを行うための正確な方法ではないことは私には明らかでした。しかし、それらのアイデアは何度も再発見されると思います。次の10年間で、それが多くの人が目指す方向性だと思います。
これがあなたに聞こえそうで、フロントエンドの作業が好きな場合は、（PHPの音から、私は個人的には何でも好きですが）好きなサーバー言語で動作するいくつかの単純なサイトを取得した後、JavaScriptを学ぶことをお勧めします http://angularjs.org/ のような人気のあるMVCフレームワークを取得し、それを使用してインタラクティブなアプリケーションを作成しようとします。機能するものと機能しないものに細心の注意を払い、独自の理論を作成し、実験し、フィードバックを得てください。そうすれば、未来が到来したときに、未来に先んじることができます。
（この回答はどのように長くなったのですか？まあ、書かれています、投稿するのもいいかもしれません。）
どのモデルでも機能します。 MVCはWebの前の概念であり、大きな巨大なhttpの壁を使って物事をこなすシナリオには、完全には適合しません。また、実際に使用するよりも「深刻な音」の重みをもたらす、負荷の高いマーケティング用語でもあります。
コントローラの役割はアプリのロジックであると思いますが、MVCの古いバージョンはそれに同意しています。
私はモデルをビジネスロジックと考えています。
DB（私の心の中で）は分離する必要があります。ログインの詳細は、DBとやり取りするアプリロジックの問題です。これは、そのユーザーが25％の割引を受けるかどうかはビジネスロジックの問題ですが、DBにも関連しています。
サーバー側のユーザーはブラウザです。コンピュータの前の男ではありません。 Webアプリは基本的に2つのアプリと考えるのが一番です。サーバー側でのあなたの仕事は、ブラウザが使用できるものを提示することです。
多くのMVC定義で正しいですか？おそらくそうではありませんが、1つを除いてすべてを壊したいという点でアプリケーションを検討しています。 DBの動作は異なる場合がありますが、それ以外はすべて維持できます。クライアント側では別のHTMLが必要になる場合がありますが、それ以外はすべて保持します。同じDB、Bizロジック、HTMLが必要かもしれませんが、ユーザーの認証方法や、HTMLの作成/テンプレートの必要性などのアプリロジックの詳細によって、さまざまな変更が生じる可能性があります。
あなたがコントロールしているとき、それらはあなたに分割されることが重要なので、ものを分割します。 MVCを行う「一方通行」を支持する人々は、当初考えられていた方法でそれを行っていないので、正しく行っているかどうか心配する必要はありません。ちょうどあなたのために何が正しいかを理解してください。