MVCのMはどこにありますか？

アプリケーションをMVCにリファクタリングしようとしていますが、Mの部分にこだわっています。

データベース対応のアプリでは、モデルはアプリのコードに実装されますよね？

しかし、その後、データベースには何がありますか？それはモデルではありませんか？

（データベースを単純なオブジェクトストアとして使用していません。DB内のデータはエンタープライズ資産です）。

ええ、コードとデータベースの両方のモデルが「モデル」です。

モデルはアプリケーションの「IS」と関係があり、コントローラーは「行う」ことです。データベースへの直接永続性を扱うコードはすべてモデルと見なされます。

注： MVCはパターンですので、考えすぎないでください。MVCを適切に実行するのは簡単ですが、結局のところ、それは単なる考え方です！それはあなたのビジネスロジックをデータベースとUIから締め出すことを意味します-それだけです。MVCの前は、サーバー上にある必要があるときにビジネスロジックをWebページにすべて表示するか、データベース内で多数のスクリプトを実行して、永続性コードとともにビジネスロジックを実行していました。MVCは、コードを再利用可能にする方法で人々が考え始めるようにするためにもたらされました。

Trygve Reenskaugは、1978年にMVCパターンを説明した最初の論文を書きました。彼の説明のモデルは、実世界のオブジェクト、現象、および概念を表すオブジェクトモデルでした。データベースを使用したアプリケーションのシナリオでは、モデルはデータの投影です。簡単に言えば、モデルはアプリケーションが関係するクラスとその関係です。

実際には、通常、MVCで使用される2つのモデル、ドメインモデル（データベースへのマッピング）とアプリケーションモデル（今日の用語ではビューモデルとも呼ばれます）があります。アプリケーションモデルは、ドメインモデルの投影であり、ビューをレンダリングするためのビュー固有のデータも含まれています。このアプローチはMMVCと呼ばれます。コントローラーはドメインモデルと直接対話し、アプリケーションモデルをビューに提示します。MVVMパターンでは、アプリケーションモデルとコントローラーが組み合わされています。

1. MVC用のデータベースは必要ありません。あなたのモデルがたまたまデータベースと通信するのであれば、それは素晴らしいことです。また、それ自体をフラットファイルに保持することも、まったく保持しないこともできます。

2. モデルは、アプリケーションのメモリにデータが保存される場所です。また、モデルを使用して、データの計算と検証を行うこともできます。たとえば、金利、期間、原則などのプロパティを持つFinancePaymentモデルがあるとします。getMonthlyPayment（）メソッドをモデルに追加して、毎月の支払いを計算できます。コントローラーやビューでそれをしたくないでしょう。

3. ビューは、ロジックをまったく持たないか、単純なデータバインディングのみを使用して合理的に愚かである必要があります（Martin Fowlerのサイトのパッシブビューと監視コントローラーパターンを参照）。ビューは、ユーザーがボタンをクリックするなどの操作を行うとイベントを発生させます。

4. コントローラーは、イベントの処理（ユーザーが[保存]ボタンをクリックしたときにコードを実行）、モデルプロパティの設定、およびモデルのロードと保存（永続性を使用する場合）の実行を担当します。コントローラーは、モデルのデータに対して計算を行ってはなりません。ただし、コントローラーでは、「if model.profit（）<0 then widget.colour = 'red'」など、ビューに代わっていくつかの計算を行う場合があります

5. モデルを変更せずに、モデルの機能を失うことなく、アプリケーションのコマンドラインバージョンに切り替えることができるはずです。

a。ビューを切り替えるだけで（コントローラーやモデルではなく）、モバイル版のアプリケーション（デスクトップ版ではなく）に切り替えることができるはずです。GUIテストフレームワークがなくても、モデルとコントローラーを単体テストできる必要があります。

モデルは、フロントエンドでVおよびCに接続し、バックエンドで永続ストレージ（ファイルからSQL / NoSQLデータベースに至るまで）に接続するコードです。dbからロードしてdbに保存するコード（モデルの誤解の1つ）だけでなく、実際にすべての「ドメイン」作業を行うコードです-選択、フィルタリング、変更、計算、決定データ。アプリケーションのすべての非UIロジックが含まれます。

非常に単純で理想的な見方をします。

モデルは通常、データのモデルとしてではなく、ドメイン（おおまかに言ってビジネス）のモデルと見なされます。これらは似ているように見えますが、互いに完全に結び付けられているわけではありません。

ビューはアプリケーションフロントエンドのモデルであり、コントローラーはあるビューから別のビューへのフローのモデルである必要があります。

データベースであろうとコードであろうと、ビジネスロジックはモデルに完全にカプセル化する必要があります。いくつかのビジネスロジックはビューまたはコントローラーで繰り返される場合がありますが、さまざまな理由で、これら2つのコンポーネントを完全に削除し、別のフロントエンドをその場所に配置することが可能（かつ安全）です。

私の理解では、MVCはクライアントアプリケーションのアーキテクチャパターンの単なる説明です。ウィキペディアの写真はこれを示しています。

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

もちろん、アプリケーションの一部が「ストアドプロシージャ」に実装されている場合、それらのデータベースコードはモデルの一部である場合も、コントローラーの一部である場合もあります（コードの機能によって異なります）。しかし、そうでない場合、データベースは明らかに「MVCの外部」にあります。

But then, what is in the database -- is that not also the model?

いいえそうではありません。 「モデルは、アプリケーションドメインの動作とデータを管理します」。多くの場合、モデルはデータベースにフックしますが、それは決して要件ではありません。モデルは、アプリケーションとデータベースの間の新しいレイヤーです。バックエンドは、一連のMockオブジェクト、XML、またはデータの永続性をサポートするその他のものです。

レイヤーを分離することにより、より優れた単体テスト手法を使用するための柔軟性が大幅に向上し、コードの管理が容易になります（EG SQLはOracleに置き換わります）。

同じことがコントローラーにも当てはまります。MVCは、コントローラーを2つのレイヤー間の仲介者として定義します。MVCには「ビジネスレイヤー」は定義されていません。むしろ、独自に追加します。MVCは、ほとんどのアプリケーションの構築に必要なすべてのレイヤーをカプセル化しません。これは、基本構造の一般的なガイドラインにすぎません。

これらの分離は、制御の反転を機能させるための鍵です。

データベースは、モデルの実装の詳細です。モデルは完全なドメインモデルであり、データとプロセスを結合する必要があります。分離は、プロセスとそのプロセスに関連するデータとの間ではなく、差異の懸念の間でなければなりません。

参照：http : //martinfowler.com/bliki/AnemicDomainModel.html

実際には非常に単純で、「モデル」はデータインターフェイスの抽象化を表します。それが理由です：

• データベースは Modelの一部と見なされますが、モデル自体ではありません
• モデルの データは、データベース、ファイル、Webサービスから取得することも、偽装することもできます。
• MVC、HMVC、または同様のフレームワークのモデルクラスにはクエリを格納する必要があります（「脂肪モデル、スキニーコントローラー」の原則[ 1 ] [ 2 ] [ 3 ]を参照）

そして、もし私が正しいなら、だれかがMVCコンテキスト外のモデルを参照するとき、誰かがデータの構造（スキーマなど）を参照する可能性が高いのはそのためです。

Mにはいくつかのロジックが含まれており、データをDBに保存すると思います。コントローラーはどのモジュールを実行するかを呼び出し、このモジュールはロジックを実行し、DBにデータを保存します（永続レイヤーがある場合があります）。その後、このモジュールはVに値を返します。

MVCのM（odel）はモデルをキャプチャする必要がありますは、ビジネス/ドメインのを1か所でます。

理想的にはビジネスルールを含める必要があります、ドメインのとその構造をがあります。

C（コントローラー）は、理想的には、ビジネスモデルの情報をプレゼンテーション（ビューなど）に仲介し、V（iew）からユーザー入力を取得してモデルの状態の変更を開始することのみに関与します。

データベース層は、特定の時点でのモデルの状態の永続性のみを処理します（むしろ処理するだけです）。

そのようなものとして、それは何かない属するいずれかにモデル又はコントローラ MVCパターンの一部ではなく、それは、ファサードの関数として（透過モデルに変更を永続化することによって暗黙的に実現することができる完全に独立した懸念が提供されコントローラーへのモデルとの相互作用）、または頻繁に行われるように、モデルに変更を加えた後にコントローラーによって明示的に呼び出されます。

理想的な世界のモデルには、ビジネスロジックのみを含める必要があり、家などの実際のオブジェクトをモデル化します。ただし、ほぼすべての状況で、モデルはデータを何らかのストレージに保持する必要があります。

モデルと保存されたデータとの相互作用は、別のデータレイヤーで発生するか、モデル内で直接発生します。これは、ORM（Object Relational Mapper）を使用する場合です。言い換えると、モデルはデータベースに直接接続するか、データベースに接続する他の「データアクセス」オブジェクトにデータを渡します。

ORM（オブジェクトリレーションマッパー）は、データベーステーブルのフィールドをモデルオブジェクトの属性にマップし、ゲッターとセッターを提供します。この場合、独立したデータレイヤーはなく、モデルはそのデータの永続化に直接責任を負います。

以下は、ActiveRecord人気のあるORM を使用したRubyの例です。

class House < ActiveRecord::Base
end

house = House.new
house.price = 120000
house.save

Priceオブジェクトにゲッターとセッターを追加するhouses自動検出されるテーブル内のフィールドActiveRecordです。いつsaveに呼び出され、価格属性の値は、データベースに永続化されます。

私の観点から見ると、データ層を持つことの長所は、モデルに到達する前にデータを操作できるポイントを得ることです。モデルは心配が少なく、責任が少なくなります。たとえば、互換性のない複数のデータソースからのデータを結合する必要がある場合、これはORMで簡単に処理できないものです。

主な短所は、管理するもう1つの抽象化層であり、不要な場合は気にせず、シンプルに保ちます。可動部品が少なく、誤作動が少ない。

はい、あなたは正しいです。

（モデルビューコントローラー）

データ（モデル）をユーザーインターフェイス（ビュー）および処理（コントローラー）から分離するアプリケーションを構築するためのアーキテクチャ。

実際には、MVCビューとコントローラーは密接に関連しているため、多くの場合、単一のオブジェクトに結合されます。MSDNによると

コントローラーは、ユーザーからのマウスとキーボードの入力を解釈し、モデルに通知したり、 the view to change as appropriate.

この図を確認してください。

たとえば、コントローラーコードはデータの要求を検証し、それをビューに返します。View-Controllerオブジェクトは1つのモデルのみに関連付けられています。しかしながら、a model can have many view-controller objects associated with it.