最佳实践，以实现业务逻辑的验证 - 实体框架

Question

我使用实体框架是第一次，我需要插入新对象到数据库之前添加业务逻辑，这里是我想过的选项：

通过在实现验证层的自定义类使用OnPropertyChanging局部方法

裹所生成的代码重写SaveChanges方法

实现业务逻辑为每个实体 -

1. 实现对DataContext的级别的业务逻辑。

对实体框架管理业务逻辑时

Answer 1

看看validation with EF - 验证是在实体内部进行的。

这是一个非常干净的方式来组织您的项目。

当您有POCO s时，实体验证的明显位置在POCO本身中。

有意义的是，Customer对象的任何验证实际上都在Customer类中。

Answer 2

也许你的答案矗立在放入系统线路哪种方法是最好的做法;）

Best practice entity validation in ASP.NET MVC & ADO.NET Entity Framework

Answer 3

另一种方式要考虑的是完全组件化你的数据访问层完全来自业务逻辑层。

创建一个只能直接访问实体框架的数据访问接口，然后在一个单独的项目中，我将创建您的业务逻辑类，它通过接口与数据访问层进行交互。您的业​​务逻辑项目中没有实体框架参考。

通过这种方式，这些图层被组件化，并且更易于作为用于两层或三层访问的多个程序集进行分发。

Answer 4

也许尝试阅读有关Specification pattern

Answer 5

我的经验：

1. 这工作，但它是相当不少，其中必须验证这可以慢许多实体的情况下工作，。其实EFv4.1会自动完成此操作。
2. 我不喜欢这种方式 - 它只服务于单个属性更改，不适用于需要在获取有效状态之前修改多个属性的复杂验证。
3. 也许 - 我喜欢根据需求进行验证。每个实体都可以暴露Validate方法来检查整个实体的状态是否正确。

但是，只有您总是使用整个实体，所有这些才有效。一旦开始使用部分更新和其他功能，您仍然需要在别处处理验证。这是另一个用于验证需求的+1。

Answer 6

我更喜欢数字3的一个版本。我喜欢抽象实体框架using a repository或类似的东西，以防我将来/需要替换EF。然后对于验证/业务逻辑，我使用任何验证技术对应用程序有意义，但通常是DataAnnotations（用于UI最小验证）和验证框架（如Fluent Validation）的最大验证/业务规则的组合。这个验证/业务逻辑同时存在于实体类（DataAnnotations）和抽象层中，这通常是我的应用程序中的一个服务层。

Answer 7

您可以通过创建另一个部分类定义来扩展您的类，大多数EF模板将实体定义为仅供人们轻松扩展它们的部分定义。如果你正在使用WPF或Silverlight，因为大多数东西不是直接绑定的，你可能想要这样做，你可能有一个布尔值并想将其转换为颜色等。编写转换器速度很慢，需要更多的代码然后在您的BusinessObjects上创建新的Getter。

我们一直在使用EF 4.0 STE（Self Tracking Entities）一段时间，并且我们用自己的部分定义扩展了大部分。我们改变了一些创建STE的T4模板，以允许访问自定义部分类定义上的构造函数以及其他小改进。

Answer 8

从Visual Studio杂志文章解决这个问题：

http://visualstudiomagazine.com/articles/2012/04/01/integrating-validation-with-the-entity-framework.aspx