0

似乎实现验证的最佳位置是尽可能靠近数据库，所以当我使用实体框架时，最近的对象是实体，在我的例子中是 POCO 实体。

这样做的原因是，如果我想重用这个 POCO 实体，验证是在 POCO 对象中实现的，那么在数据库中插入磨损数据的可能性就会减少。

这也避免了有人试图在创建另一个应用程序的数据库中插入不正确的数据，或者因为他没有实现验证。所以更安全。

一种方法是使用扩展 POCO 实体并实现 IValidatableObject 接口并返回验证结果列表的部分类。

但其他方式如下。我有一个通用程序集，它具有以下内容：

  • 一个接口，声明需要实现存储库的方法。
  • 存储库将使用的 POCO 实体。
  • 一类具有实用程序，例如复制实体和验证实体数据的方法。

然后我可以创建许多使用不同版本的 EF 或其他技术的存储库，并且它们都使用通用程序集。此存储库使用公共库中的方法实现验证。

在这种情况下，我只执行一次验证。唯一的问题是存储库需要调用方法来验证数据。

但从我的角度来看，这种方式有优势。例如，我可以根据操作的类型来验证实体的数据。例如，如果我要添加一条新记录，并且主键作为自动数字，如果 ID 不是 0，那么我可以抛出异常，或者如果我尝试在 ID 为 0 时删除一个寄存器，那么我不会' t 需要将命令发送到数据库。

所以第二个解决方案解决了尽可能接近数据库实现验证的问题，因为存储库中使用了存储库，即访问数据库的元素，但存在如果某些开发人员创建一个新存储库而不是使用验证方法，我可以在数据库中有不正确的数据。

所以我的问题是，最好的选择是对部分类使用验证还是使用公共库，并且验证是在存储库中实现的，这确实是用户将使用的。

谢谢。

4

1 回答 1

1

好的 - 呸，大问题。我的观点是，应用程序的 APPLICATION DOMAIN 是一切的老板。数据库只是一个附加服务。因此，应用程序域最终应该验证在某处发送的所有对象。无需验证来自数据库的对象，因为它们已经过验证。

例如，如果您正在创建一些需要发送到 Web 服务并且需要验证的对象，该怎么办。可以说它永远不会靠近数据库或存储库。一旦验证了 DOMAIN 业务对象，就可以将它们发送到持久性或其他任何地方。

要考虑的另一件事是验证的含义。这是否意味着数据类型正确？这是否意味着业务对象有效？这是否意味着业务对象在给定的上下文中有效？它可能意味着所有这些事情，也可能只是其中一些事情。

例如，如果您的系统允许用户部分更新记录（常见于很长​​的输入表单），该怎么办。业务对象可能仅在捕获所有所需数据时才有效，但数据库允许“部分”数据的持久性。换句话说，您可以将业务对象保存到数据库中，尽管它还不能用于进一步处理。等等等等……

于 2013-09-04T18:26:04.590 回答