我应该如何分离实体方法？答案

【问题标题】：How should I separate entities methods?我应该如何分离实体方法？
【发布时间】：2010-12-23 04:55:45
【问题描述】：

SO的好人，

今天我对我的业务层设计有一些严重的担忧。它基于实体 POCO 对象和我想为这些实体添加逻辑但是，有两种类型的逻辑：

我的问题很简单：

我应该如何区分这两种？

首先，我正在考虑将这两个作为方法添加到实体中。并使用部分类来拆分它们。

其次，我认为我不想要一个具有很多方法的超重对象。所以也许为什么不使用静态类或单例的方法来做 LinqToEntities 的东西，而将纯 C# 留在实体方法中。然后我会有几个按功能分组的类提供逻辑，实体作为参数传递给类方法。

这真的让我很困扰，因为第二种解决方案看起来更干净，但看起来它打破了面向对象的范式。另一方面，第一个似乎是一种反模式。

你怎么看？你有解决这个悖论的好办法吗？

精神分裂编辑：实际上我所说的持久性逻辑应该去 DAL 和 BLL 中的纯 c# 逻辑。 POCO 实体由 DAL 生成。然后我可以在我的 BLL 中扩展这些实体以添加方法。在我的 DAL 中，我应该构建第二个解决方案中公开的逻辑。

【问题讨论】：

呃，你为什么说第二种方法打破了 O-O 范式？具体有哪些方式？这是您对选项 2 的唯一关注吗？
在 OO 中，您向对象发送消息。在第二个解决方案中，您将对象作为将完成这项工作的方法的参数传递。它看起来像 OO 仿真：以对象作为第一个参数的静态方法。这是我唯一关心的问题，我只是想避免一个超重的实体。
在这种情况下，您的实体所做的一切将比业务实体应做的多很多倍。无论如何，我不是处于最佳位置来衡量这一点。 :)

【解决方案1】：

描述实体应该如何保存/加载的逻辑不属于实体本身；它更有可能是持久服务、数据访问对象等的角色。

我会让对象中的对象特定逻辑——我们在这里讨论对象行为，然后创建一个服务来处理这种对象类型的持久性问题。

【讨论】：

mmmh，我在 SOA，所以我不想创建持久性服务。它会破坏架构。看，这个 bll 将是一个服务，如果这个服务必须依赖一个持久化服务，那么它就不是自治的......
我认为您在这里混合了不同的概念。考虑到您正在谈论的服务是您的 SOA 架构的一个组件。这是一个粒度问题：这个组件有它自己的设计。当我谈论持久性服务时，我不是在谈论您的 SOA 生态系统的另一个高级独立服务——我在谈论您现有服务的一个可能的内部组件。 “持久性服务”可以是一个简单的类。如果您愿意，请阅读“数据访问对象”。