Linq实体和​​业务逻辑

Question

每当我在linq上阅读一篇关于实体的文章时，我听起来应该将我的业务逻辑嵌入到生成的实体类中。

这意味着业务对象（控制器，服务层......）的“用户”必须知道使用linq所需的datacontext对象。

这也意味着DAL逻辑和业务逻辑将会混淆。

很多微软的例子都使用某种DTO方法。我不是DTO模式的忠实粉丝。

我应该让业务对象封装linq-entity并使用属性提供对它的访问，还是应该坚持使用DTO模式？

你有什么建议？

由于

Answer 1

实体模型生成部分类。在我的项目中，我在类库中使用实体模型，并向其添加了一些.cs文件，为默认实体类添加了功能。 （主要与错误和消息记录到数据库表相关的函数以及将所有数据导入/导出到XML的方法。）

但真正的业务逻辑位于引用此实体类库的第二个类库中。

---

我们来解释一下。首先，我从数据库创建了一个实体模型。它包含公司名称和地址列表。我这样做是通过选择“新项目|类库”，然后将ADO.NET实体数据模型添加到此库。实体模型将链接到我的SQL Server数据库，导入我需要的表并自动为我想要访问的表创建类。 然后，我为每个要扩展的表添加第二个.cs文件。这将是一些与数据库紧密相关的原始方法。 （主要是导入/导出方法和错误记录。）我将调用Entity.Model，它将编译为Entity.Model.dll。

然后我添加了第二个包含业务逻辑的项目。我再次使用“New project | Class library”创建它并将Entity.Model.dll添加到它的引用中。然后我开始编写类，将特定于数据库的类转换为更逻辑的类。一般情况下，除了我将保护或隐藏某些字段并添加一些计算字段之外，我不需要做很多更改。业务逻辑只会公开我想从客户端应用程序访问的功能，而不是更多的单一方法。因此，如果我不允许客户删除公司，那么实体模型中的“删除”功能将不在业务层中公开。也许我想在公司更改地址时发送通知，因此我将添加一个在公司地址字段更改时触发的事件。 （这将写一个消息日志或其他。）我将称之为business.logic，它编译为Business.Logic.dll。

最后，我将创建客户端应用程序并添加对Business.Logic.dll的引用。 （但不是实体模型。）我现在可以开始编写我的应用程序并通过业务层访问数据库。除了通过实体模型修改数据库之外，业务层还将执行验证，触发一些事件并执行任何其他操作。而实体模型只是为了保持数据库关系的简单，允许我通过数据库中的所有外来链接“遍历”数据。

Answer 2

我不会编辑生成的文件，因为它们可能会更改。

你可以做的是将它们包装成一些查询对象并传递它。

ayende makes a very good point关于DAL应该居住的地方

另外，你应该是viewmodels / dtos的粉丝;）

Answer 3

我更喜欢将调用包装到业务类中的实体类中。 （简称为BC。）每个BC都有几个构造函数，其中一个或多个构造函数允许将上下文传递给它。这允许一个BC调用另一个BC并在相同的上下文中加载相关数据。这也使得处理需要共享上下文更简单的BC集合。

在不接受上下文的构造函数中，我在构造函数本身中创建了一个新的上下文。我通过其他BC可以访问的只读属性来提供上下文。

我使用MVVM模式编写。关于这种方法的好处是，到目前为止，我已经能够编写我的视图模型而无需引用数据上下文，只是形成我的模型的BC。因此，如果我需要修改我的数据访问权限（替换实体框架，或者在测试结束时升级到版本4），我的视图和视图模型将与BC中所需的更改隔离开来。

不确定这是最好的方法，但到目前为止我还是喜欢这个结果。确实需要通过调整才能正确设计BC，但我最终得到了一组灵活，可扩展且可维护的类。