Question

存储在关系数据库中的数据具有数据约束（例如最大字符串属性长度）。客户端使用数据访问库（DAL）以ORM方式管理数据（存储库+数据域类）

你个人会在哪里实施限制？例如：

数据域类：

class Person
{
 private string _name;
 public string Name 
 {
   get { return _name; }
   set { _name = StringHelper.Truncate(value, 50) }
 }
 ...
}

或者可能是存储库：

PersonRepository {
  public void CreatePerson(Person p) {
    p.Name = StringHelper.Truncate(p.Name, 50);
    ... 
    DataContext.Insert(..);
  }
}

或者您可能会使用分配给数据域类属性的属性，这些属性将在存储库方法中通过反射进行自动字符串字段截断。

class Person {
   [StringConstraint(MaxLength = 50)]
   public string Name { get; set; }
} 

PersonRepository::CreatePerson(p) {
  EntityHelper.ApplyConstraints(p);
  ...
}

或者可能是别的什么？

提前谢谢！

Answer 1

我会在业务逻辑层中执行它，其业务逻辑类与数据库相关的类不同。我不会冒出sql错误甚至在数据库中强制执行它。在我看来，数据库应该只关注数据的形状和一致性。不是实际数据本身。

您的约50个字符的规则是业务规则，而不是逻辑，关系或“结构”规则。它可以很容易地是51个字符或49.你任意选择50，这很好。这就是业务层对象的用途。执行这些规则。

对您的数据的任何业务访问都应该再次通过业务层，通过服务公开，直接引用或您选择的其他方法。

对数据库的唯一“直接”访问应该再次关注数据的形状和一致性，而不是实际数据本身。诸如备份，复制，集群，负载平衡，审计等等。

因此，ORM类只是Person的业务对象与实际数据库中Person的存储之间的粘合剂。数据库应该只关心数据库的整体形状和结构以及实际数据存储的底层基础结构和机制。业务对象应确定对象的“本质”并定义它的真实含义。一个人应该总是至少有一个名字，他们的年龄不能超过110岁，他们的身高不能超过7英尺等。

无论如何，这是我的哲学/经验法则： - ）

Answer 2

约束是验证的一部分。 Business层负责验证对象，但在UI中使用相同的验证逻辑也很方便。分享这种逻辑的方法是使用一些API来标记具有验证属性的数据对象。您可以在BL和UI中运行相同的验证。 DataAnnotations提供此功能，也可以使用Validation应用程序块实现。

编辑：这并不意味着您不会在数据库中放置约束。这只意味着您应该能够尽快检测到约束违规，以保存到数据库的往返。

Answer 3

在数据库中是我的偏好如果有人试图插入太长的字符串，将返回SQL错误。应用程序通过向用户显示有用的消息来处理该错误。

如果有人有备用访问权限 - SSMS或其他应用程序代码，它也会集中。

DAL。建模数据约束最佳实践

3 个答案: