达尔。数据约束建模最佳实践

发布于 2024-09-15 15:00:14 字数 782 浏览 1 评论 0原文

存储在具有数据约束的关系数据库中的数据（例如最大字符串属性长度）。客户端使用数据访问库 (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);
  ...
}

或者可能是别的什么？

先感谢您！

原文

Data stored in relation database with data constraints (for example maximum string property length). Clients use Data Access Library (DAL) to manage the data in ORM manner (repositories + data domain classes)

Where would you personally implement constraints?
For example:

Data domain classes:

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

Or may be repository:

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

Or may be you shall use attributes assigned to data domain classes properties that would be processed in repository methods via reflection for automated string fields truncation.

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

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

Or may be something else?

Thank you in advance!

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

天冷不及心凉 2024-09-22 15:00:14

我会在业务逻辑层中使用与数据库相关类不同的业务逻辑类来完成此操作。我不会冒泡 SQL 错误，甚至不会在数据库中强制执行它。在我看来，数据库应该只关心数据的形状和一致性。与实际数据本身无关。

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

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

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

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

无论如何，这就是我的哲学/经验法则:-)

回复收藏 0 原文