我应该如何区分实体方法？

Question

SO的好人，

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

1. 纯C＃逻辑
2. 持久性逻辑（在我的情况LinqToEntities）

我的问题很简单：

我应该怎样单独这两种？

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

其次，我认为我不希望超重对象与许多方法。 因此，也许为什么不使用静态类或单例执行LinqToEntities的方法，并将纯C＃留在实体方法中。 然后我会有几个类按功能分组提供逻辑，该实体作为参数传递给类的方法。

它确实让我困扰，因为第二种解决方案看起来比较干净，但它看起来像打破了面向对象的范例。另一方面，第一个看起来像是反模式。

您认为如何？你有解决这个悖论的明智解决方案吗？

精神分裂症编辑：实际上我称之为持久性逻辑应该去BLAL中的DAL和纯粹的c＃逻辑。 POCO实体由DAL生成。然后，我可以在我的BLL中扩展这些实体以添加方法。在我的DAL中，我应该将第二种解决方案中暴露的逻辑结构化。

Answer 1

描述实体如何保存/加载的逻辑不属于实体本身;它更可能成为持久性服务，数据访问对象等的角色。

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