实体应该有行为吗？或者不？

为什么或者为什么不？

如果不是，是否违反了封装？

解决方案

如果我们严格遵循MVC，则模型(实体)将没有任何固有行为。但是，我的确包括任何有助于最简单地管理实体持久性的助手方法，包括有助于维持其与其他实体关系的方法。

这取决于它们是哪种类型的实体，但是术语"实体"至少对我而言意味着业务实体，在这种情况下，它们应该具有行为。

"业务实体"是真实世界对象的建模，它应封装对象表示在软件上下文中具有的所有业务逻辑(行为)和属性/数据。

如果实体没有行为，则我们不是在编写面向对象的代码。如果一切都用getter和setter完成，并且没有其他行为，那么我们正在编写过程代码。

许多商店表示，当他们保持实体哑巴时，他们正在实践SOA。他们的理由是数据结构很少更改，而业务逻辑却可以更改。这是一个谬论。有很多模式可以解决这个问题，并且它们并不涉及将所有事情都减少到大量的吸气剂和吸气剂上。

如果我们打算将实体暴露给世界，那么最好(通常)使行为不受实体的影响。如果要集中化业务操作(即ValidateVendorOrder)，则不希望Order具有运行某些逻辑以进行自我验证的IsValid()方法。我们不希望该代码在客户端上运行(如果他们捏造了该代码，即类似于不提供任何客户端UI来设置放置在购物车中的商品的价格，而是在URL上张贴虚假价格。我们没有服务器端验证，那就不好了！复制验证是多余的...干(不要重复自己)。

在实体上执行行为时不起作用的另一个示例是延迟加载的概念。今天，在实体上访问属性时，许多ORM允许我们延迟加载数据。如果我们要构建3层应用程序，那么这将不起作用，因为客户端最终会在访问属性时无意间尝试进行数据库调用。

这些是让行为远离实体的最重要的论据。