我看到这个术语常用，就好像在讨论面向对象语言的MVC时两者之间有一个具体的区别。从我从上下文中得到的是，商业模型执行一个动作来改变数据模型。这是表达差异的正确方法。
我想让我感到困惑的是，大多数模型的例子都混合了这些角色，表面上看起来很自然。通常，更改对象状态的方法位于这些对象本身内部。我想我无法想出一个如何在现实世界中运作的例子。更改对象的方法在该对象内部似乎更自然。任何人都可以更清楚地解释一下吗？
答案 0 :(得分：1)
“商业模型”和“数据模型”都可以被视为MVC应用程序中“M”层的子层。它们都与保存和加载数据有关。不同之处在于，第一个更接近最终用户看到需求和功能的方式，第二个更接近低级数据库操作。
数据模型层始终更依赖于数据在应用程序中持久化的具体方式。从数据库开始（或者是您持久化数据的具体方式 - 它可以是平面文件或XML），它是第一个，最不抽象的软件层。例如，如果您在应用程序上使用Oracle RDBMS，那么数据模型就是放置任何Oracle特性的地方，例如特定的SQL语句，连接等。这也是实现原子数据操作的地方（例如CRUD SQL语句） ）。当然，有一些方法可以使这个层更少依赖于给定的RDBMS，比如使用某种ORM库，如Hibernate（Java），NHibernate（.NET）或Doctrine（PHP）。
如此“低级”，数据模型不应该由应用程序的其余部分直接使用。这是商业模式的作用。
商业模式位于上层抽象层次。它实现了封装应用程序所需的所有功能需求的服务。
业务模型不应该依赖于特定的RDBMS - 它应该使用数据模型来完成这项工作。另一个区别是它暴露了不太精细的方法 - 不是CRUD的东西，而是更复杂的，依赖于业务的功能。当然，它也应该不依赖于表示层（视图和控制器）。
例如，根据文字值更改单个员工薪水的方法可能属于数据模型（考虑到最终用户不允许使用此类功能）。但是，增加给定百分比的所有工资的方法肯定属于业务模型（它可以迭代所有员工，并首先使用“单一员工更新”，例如数据模型方法来实现此规则）
但请记住，这是一个“按书”描述 - 现实世界的场景是不同的。有时我们可能不需要两个不同的数据层 - 例如，ActiveRecord模式既可以用作数据模型类，也可以用作Business类。在这种情况下，您可以将两个层组合成一个层 - 但我绝对不建议在更复杂的场景中使用此方法。
答案 1 :(得分：1)
MVC实现中的模型是或应该是业务模型。
业务模型描述了与应用程序相关的业务实体的行为和属性。当您对此进行编码时，实体将成为类，行为和属性将分别作为这些类的方法和属性。
应用程序需要某处存储其信息。如果内存是无限的，我们永远不会停电，我们的操作系统永远不会需要重启，商业模式就足够了。然而，在现实世界中，我们需要将类的属性存储在应用程序和/或计算机关闭的地方。
因此业务模型需要并使用某种类型的数据存储。数据存储的组织方式是数据模型。在大多数情况下，关系数据库是首选的数据存储，数据模型通常是关系数据库的设计。
虽然数据模型可以处于逻辑级别，然后更接近于OO业务模型，但在此上下文中，我们通常讨论逻辑模型的技术实现。 （一个关键区别：逻辑模型允许表之间的M-N关系，规范化技术模型将具有与两个原始表具有N-1关系的链接表。）
业务模型的OO特性不直接映射到规范化的表和列设计。 ORM（对象 - 关系 - 映射）库通常用于将类的属性映射到关系数据库中的表和列。
由于业务模型使用数据存储并因此使用数据模型，并且它们一起构成MVC实现中的模型，因此它们之间的区别常常变得模糊。我认为非常值得在他们的脑海中保持他们各自的角色。它有助于决定逻辑应该去哪里。
例如，与rsenna的回答相反，我会满足于改变单个员工的薪水仍然是商业模式的一个功能，即使将其更改为字面值，因为商业模式可能会定义各种检查和余额，验证和其他业务规则，以改变员工的工资。例如，企业可以制定规则，任何工资的变化都不会超过x％，可能永远不会超过CEO的工资，符合工会规则等。
虽然以数据库为中心的开发人员和许多dba都不同意，但这些规则属于业务模型，而不属于数据模型。 DBa在数据模型中更喜欢它们，可能是因为业务模型通常是用某种编程语言实现的，数据库中的数据模型和dba就像保持数据库的美观，有效和一致。
我会说规则仍然是业务模型的一部分，而不是数据模型，但您当然总是选择在触发器和存储过程中实现它们（以及）。实施商业模式规则的地方是......，很好的实施，细节。
答案 2 :(得分：0)
业务模型包括数据流如何在业务功能内移动。这不会考虑数据模型，但有助于指导数据的存储方式。
数据模型是在考虑数据的基础上构建的 - 业务模型的逻辑基于流程/过程/仅仅是事情的流程，数据模型旨在以最规范化的方式构建数据可能会反映商业模式的需求。