オブジェクト指向言語の MVC について議論するとき、この 2 つの間に具体的な違いがあるかのように、この用語がよく使われます。私が文脈から得たのは、ビジネスモデルがデータモデルを変更するアクションを実行するということです。それは違いを表現する正しい方法ですか。
私を混乱させているのは、モデルのほとんどの例がこれらの役割の両方を混在させており、表面的にはそれが自然に感じられることだと思います. 多くの場合、オブジェクトの状態を変更するメソッドは、それらのオブジェクト自体の内部にあります。これが現実の世界でどのように機能するかの例を思いつくのは難しいと思います。オブジェクトを変更するメソッドがそのオブジェクト内にある方が自然に思えます。これをもう少し明確に説明できる人はいますか？
MVC アプリケーションでは、「ビジネス モデル」と「データ モデル」はどちらも「M」層のサブ層と見なすことができます。どちらもデータの保存と読み込みに関連しています。違いは、前者は要件と機能がエンド ユーザーに見える方法に近く、後者は低レベルのデータベース操作に近いことです。
データ モデル層は、アプリケーション全体でデータを永続化する具体的な方法に常に依存しています。データベース (または、データを永続化する具体的な方法は何でも - フラット ファイルや XML など) から始めて、最初の、最も抽象度の低いソフトウェア層です。たとえば、アプリケーションで Oracle RDBMS を使用している場合、データ モデルは、特定の SQL ステートメント、接続など、Oracle の特性を配置する場所です。また、アトミック データ操作 (CRUD SQL ステートメントなど) を実装する場所でもあります。 ）。もちろん、Hibernate (Java)、NHibernate (.NET)、Doctrine (PHP) などの ORM ライブラリを使用するなど、この層が特定の RDBMS にあまり依存しないようにする方法はあります。
非常に「低レベル」であるため、データ モデルはアプリケーションの残りの部分で直接使用しないでください。これがビジネスモデルの役割です。
ビジネス モデルは上位の抽象レベルに配置されます。アプリケーションが必要とするすべての機能要件をカプセル化するサービスを実装します。
ビジネス モデルは、特定の RDBMS に依存するべきではありません。データ モデルを使用してこの仕事を行う必要があります。もう 1 つの違いは、CRUD のものではなく、より複雑でビジネスに依存する機能である、より粒度の低いメソッドを公開することです。もちろん、プレゼンテーション層 (ビューとコントローラー) に依存するべきではありません。
たとえば、リテラル値に基づいて 1 人の従業員の給与を変更するメソッドは、おそらくデータ モデルに属します (そのような機能がエンド ユーザーに許可されていないことを考慮して)。しかし、特定のパーセンテージですべての給与を増やす方法は、確かにビジネス モデルに属します (たとえば、すべての従業員を反復処理し、最初の「単一の従業員の更新」というデータ モデル メソッドを使用してこのルールを実装することができます)。 .
ただし、これは「本による」説明であることを覚えておいてください。実際のシナリオは異なります。また、2 つの異なるデータ層が必要ない場合もあります。たとえば、ActiveRecord パターンは、データ モデル クラスとビジネス クラスの両方として使用できます。この場合、両方の層を 1 つの層に混在させますが、より複雑なシナリオでこのアプローチを採用することは絶対にお勧めしません。
MVC 実装のモデルは、ビジネス モデルであるか、そうあるべきです。
ビジネス モデルは、アプリケーションに関連するビジネスのエンティティの動作と属性を記述します。これをコード化すると、エンティティはクラスになり、動作と属性はそれぞれそれらのクラスのメソッドとプロパティになります。
アプリケーションには、その情報を保存する場所が必要です。メモリに制限がなく、停電や OS の再起動が不要であれば、ビジネス モデルとしては十分です。ただし、現実の世界では、クラスのプロパティを、アプリケーションやコンピューターのシャットダウンに耐えられる場所に保存する必要があります。
そのため、ビジネス モデルは何らかのタイプのデータ ストアを必要とし、使用します。このデータ ストアを編成する方法がデータ モデルです。ほとんどの場合、リレーショナル データベースが最適なデータ ストアであるため、データ モデルは通常、リレーショナル データベースの設計です。
データ モデルは論理レベルにあり、オブジェクト指向ビジネス モデルにより似ていますが、このコンテキストでは通常、論理モデルの技術的な実装について話しています。(重要な違いの 1 つ: 論理モデルでは、テーブル間の MN 関係が許可されます。正規化された技術モデルには、2 つの元のテーブルと N-1 関係を持つリンク テーブルがあります)。
ビジネス モデルの OO の性質は、正規化されたテーブルと列の設計に直接対応しません。ORM (オブジェクト - リレーショナル - マッピング) ライブラリは、多くの場合、クラスの属性をリレーショナル データベースのテーブルと列にマップするために使用されます。
ビジネス モデルはデータ ストアを使用し、したがってデータ モデルを使用し、それらが一緒になって MVC 実装のモデルを構成するため、それらの区別が曖昧になることがよくあります。それぞれの役割を明確にしておくことは非常に価値があると思います。ロジックがどこに行くべきかを決定するのに役立ちます。
たとえば、rsenna の回答とは反対に、ビジネス モデルはあらゆる種類の抑制と均衡を定義する可能性があるため、1 人の従業員の給与を変更することは、文字通りの値に変更する場合でも、依然としてビジネス モデルの機能であることに満足します。従業員の給与を変更するための検証およびその他のビジネス ルール。たとえば、ビジネスには、給与が x パーセントを超えて変化してはならない、CEO の給与を決して超えてはならない、労働組合の規則に準拠している、などの規則がある場合があります。
データベース中心の開発者と多くのデータベース管理者は同意しませんが、この種のルールはデータ モデルではなくビジネス モデルに属します。おそらく、ビジネスモデルは通常、ある種のプログラミング言語で実装され、データモデルはデータベースに実装されており、DBA はデータベースを適切かつ有効で一貫性のあるものに保ちたいと考えているためです。
ルールは依然としてデータ モデルではなく、ビジネス モデルの一部であると言えますが、もちろん、トリガーやストアド プロシージャにルールを実装することもできます (同様に)。ビジネスモデルのルールがどこに実装されるかは、...、実装、詳細の問題です。
ビジネス モデルは、ビジネスの機能内でデータの流れがどのように移動するかで構成されます。これはデータ モデルを考慮していませんが、データの格納方法をガイドするのに役立ちます。
データモデルはデータを念頭に置いて構築されます - ビジネスモデルのロジックがプロセス/手順/物事がどのように行われるかの流れに基づいている場合、データモデルは可能な限り最も正規化された方法でデータを構造化するように設計されています。ビジネスモデルのニーズを反映します。