如何定义业务模型和数据模型之间的区别？
在讨论 OO 语言的 MVC 时，我经常使用这个术语，就好像两者之间存在具体区别一样。根据我从上下文中得到的信息，业务模型执行一个操作来改变数据模型。这是表达差异的正确方式吗？
我想令我困惑的是，大多数模型示例都混合了这两种角色，而且从表面上看，这样做感觉很自然。通常，更改对象状态的方法位于这些对象本身的内部。我想我很难想出一个例子来说明这在现实世界中是如何运作的。更改对象的方法位于该对象内部似乎更自然。任何人都可以更清楚地解释这一点吗？
I see the term often used as if there is a concrete distinction between the two when discussing MVC for OO languages. From what I get from context it is that business models perform an action to mutate the data models. Is that a correct way to express the difference.
I guess what confuses me though is that most examples of models mix both of these roles and on the surface it feels natural to do. Often the methods that change objects states are inside of those objects themselves. I guess I have trouble coming up with an example of how this works in the real world. It seems more natural that methods to change an object be inside that object. Can any one explain this a little more clearly?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在 MVC 应用程序中，“业务模型”和“数据模型”都可以视为“M”层的子层。它们都与保存和加载数据有关。区别在于，第一个更接近最终用户看到需求和功能的方式，第二个更接近低级数据库操作。
数据模型层始终更依赖于数据在应用程序中持久保存的具体方式。从数据库（或者任何持久数据的具体方式 - 它可以是平面文件或 XML）开始，它是第一个、最不抽象的软件层。例如，如果您在应用程序上使用 Oracle RDBMS，则数据模型是您放置任何 Oracle 特性的地方，例如特定的 SQL 语句、连接等。这也是实现原子数据操作（例如 CRUD SQL 语句）的地方）。当然，有一些方法可以使这一层减少对给定 RDBMS 的依赖，例如使用某种 ORM 库，如 Hibernate (Java)、NHibernate (.NET) 或 Doctrine (PHP)。
由于数据模型如此“低级”，因此应用程序的其余部分不应直接使用该数据模型。这就是商业模式的作用。
业务模型位于上层抽象级别。它实现封装了应用程序所需的所有功能需求的服务。
业务模型不应该依赖于特定的 RDBMS - 它应该使用数据模型来完成这项工作。另一个区别是它公开了不太精细的方法 - 不是 CRUD 内容，而是更复杂、依赖于业务的功能。当然，它也不应该依赖于表示层（视图和控制器）。
例如，基于字面值更改单个员工工资的方法可能属于数据模型（考虑到最终用户不允许此类功能）。但是，以给定百分比增加所有工资的方法肯定属于业务模型（并且它可以迭代所有员工，并首先使用“单个员工更新”、数据模型方法来实现此规则，例如） 。
但请记住，这是“按书本”的描述 - 现实世界的场景是不同的。有时我们可能不需要两个不同的数据层 - 例如，ActiveRecord 模式可以既用作数据模型类又用作业务类。在这种情况下，您可以将两个层混合为一个层 - 但我绝对不建议在更复杂的场景中采用这种方法。
"Business Model" and "Data Model" can both be seen as sub-tiers of the "M" tier, in a MVC application. They both relate to saving and loading data. The difference is that the first is closer to the way the requirements and functionalities are seen by the end-user, and the second is closer to low-level database manipulation.
The Data Model tier is always more dependent of the concrete way that the data is persisted across an application. Starting from the database (or whatever is your concrete way of persisting data - it could be flat files, or XML), it is the first, least abstract software tier. For instance, if you are using the Oracle RDBMS on a application, the data model is where you would place any Oracle particularity, like specific SQL statements, connection etc. That's also the place to implement atomic data manipulation (CRUD SQL statements, for instance). Of course, there are ways to make this tier less dependent of a given RDBMS, like using some kind of ORM library like Hibernate (Java), NHibernate (.NET) or Doctrine (PHP).
Being so "low level", the data model should NOT be used directly by the rest of the application. This is the role of the Business Model.
The Business Model is placed in a upper abstract level. It implements the services that encapsulates all functional requirements needed by the application.
The Business Model should not be dependent of a particular RDBMS - it should use the Data Model to do this job. Another difference is that it exposes less granular methods - not CRUD stuff, but more complex, business dependent functionality. Of course, it should also not be dependent of the presentation layer (views and controllers).
For example, a method that changes the salary of a single employee, based on a literal value, probably belongs to the data model (considering that such functionality is not allowed to the end-user). But a method to increase all salaries on a given percentage would certainly belong to the business model (and it could iterate over all employees, and use that first, "single employee update", data-model method to implement this rule, for instance).
But keep in mind this is a "by-the-book" description - real world scenarios are different. And sometimes we may have no need of two distinct data tiers - the ActiveRecord pattern, for instance, may be used both as a Data Model class and as a Business class. In this case you would mix both tiers into a single one - but I definitely would not recommend taking this approach on more complex scenarios.
MVC 实现中的模型是或者应该是业务模型。
业务模型描述与应用程序相关的业务实体的行为和属性。当您将其编码出来时，实体将成为类，而行为和属性最终将分别成为这些类的方法和属性。
应用程序需要在某个地方存储其信息。如果内存是无限的，我们就永远不会断电，我们的操作系统也永远不需要重新启动，那么商业模式就足够了。然而，在现实世界中，我们需要将类的属性存储在它们可以在应用程序和/或计算机关闭时幸存的地方。
因此，业务模型需要并使用某种类型的数据存储。该数据存储的组织方式就是数据模型。由于在大多数情况下关系数据库是首选的数据存储，因此数据模型通常是关系数据库的设计。
虽然数据模型可以处于逻辑级别，然后更接近于面向对象的业务模型，但在这种情况下，我们通常讨论的是逻辑模型的技术实现。 （一个关键区别：逻辑模型允许表之间存在 MN 个关系，规范化技术模型将具有一个链接表，该链接表与两个原始表具有 N-1 关系）。
业务模型的面向对象性质并不直接映射到规范化的表和列设计。 ORM（对象-关系-映射）库通常用于将类的属性映射到关系数据库中的表和列。
由于业务模型使用数据存储和数据模型，并且它们一起构成 MVC 实现中的模型，因此它们之间的区别通常会变得模糊。我认为非常值得你清楚地记住他们各自的角色。它有助于决定逻辑应该去哪里。
例如，与 rsenna 的回答相反，我认为改变单个员工的工资仍然是商业模式的一个函数，即使将其更改为字面值，因为商业模型可能会定义各种制衡，更改员工工资的验证和其他业务规则。例如，企业可以制定规则，工资变化不得超过 x%、永远不能超过 CEO 的工资、遵守联盟规则等。
尽管以数据库为中心的开发人员和许多 dba 会不同意，但这些规则属于业务模型，而不是数据模型。 DBA 在数据模型中更喜欢它们，可能是因为业务模型通常是用某种编程语言实现的，而数据库中的数据模型是 DBA 喜欢保持数据库良好、有效和一致的。
我想说这些规则仍然是业务模型的一部分，而不是数据模型的一部分，但您当然可以始终选择在触发器和存储过程中实现它们（也）。商业模式的规则在哪里实施是一个……实施得好、细节的问题。
The model in a MVC implementation is or should be the business model.
The business model describes the behaviour and attributes of the entities of the business that are relevant to the application. When you code this out, the entities become classes and the behaviour and the attributes will end up as methods and properties of those classes respectively.
The application needs somewhere to store its information. If memory were limitless, we would never have power outages and our OS's would never require restarts, the business model would be sufficient. In the real world however, we need to store the properties of the classes somewhere where they can survive application and/or computer shutdown.
And so the business model needs and uses a data store of some type. The way this data store is organised is the data model. As in most cases a relational database is the data store of choice, the data model is usually the design of the relational database.
While a data model can be at a logical level and then resembles an OO business model more closely, in this context we are usually talking about a technical implementation of the logical model. (One key difference: logical models allow M-N relations between tables, the normalized technical model will have a link table which has a N-1 relation with the two original tables).
The OO nature of the business model doesn't map directly to a normalized table and column design. ORM (Object - Relational - Mapping) libraries are often used to map the classes' attributes to the tables and columns in the relational database.
As the business model uses a data store and thus a data model, and together they comprise the Model in an MVC implementation, the distinction between them often gets blurred. I think it is very much worth keeping their separate roles clear in your mind. It helps in deciding where logic should go.
For example, contrary to rsenna's answer, I would content that changing the salary for a single employee is still a function of the business model, even when changing it to a literal value, because the business model may define all kinds of checks and balances, validation and other business rules to changing an employee's salary. For examply the business could have rules that no salary may change by more than x percent, may never exceed the CEO's salary, be compliant with Union rules, etc.
Though database centered developers and many dba's will disagree, these kind of rules belong in the business model, not in the data model. DBa's prefer them in the data model, possibly because the business model is usually implemented in some kind of programming language and the data model in the database and dba's like to keep their databases nice and valid and consistent.
I would say the rules are still part of the business model, not the data model, but you can of course always choose to implement them in the in triggers and stored procedures (as well). Where the rules of the business model are implemented is a matter of..., well implementation, detail.
业务模型包括数据流如何在业务功能内移动。这不会考虑数据模型，但有助于指导数据的存储方式。
数据模型是在考虑数据的情况下构建的 - 业务模型的逻辑基于流程/程序/只是事情如何完成的流程，数据模型旨在以尽可能标准化的方式构建数据，这将反映商业模式的需求。
Business models consist of how the flow of data moves within functions of a business. This does not take the data model into consideration, but helps guide how the data will be stored.
Data models are built with the data in mind - where the logic of the business model is based on processes/procedures/just the flow of how things are done, the data model is designed to structure the data in the most normalized way possible that will reflect the needs of the business model.