使用根持久化类或基可持久化对象是一种架构气味吗？

Question

Alt.Net社区对表示的主要不满之一是，它迫使您对存储在数据库中的所有内容使用对象。我有两个问题要问：

1. 将“根持久类”作为应用程序中域对象的基础是可以接受的，还是这是一种架构气味？
2. 如果您觉得在您的应用程序中有一个是可以的，那么一个ORM框架强迫您使用它也可以吗？是否有理由避免让您这样做的框架？

一段时间以来，我一直使用一个抽象的基对象作为我所有可动类的根。它使几个家务更容易做。

Answer 1

我的感觉是，假设上下文是这样的，它是可以的

1. 别挡道
2. 不添加不在实体作用域之外使用的特性
3. 不会将您与任何特定的ORM联系在一起(某种程度上与#2一致)

因此，如果使用基类来描述ID和“平等”的含义(因为很多情况下，如果实体具有相同的ID，则被认为是相等的)，那么就可以了。但是，当它开始描述以数据库为中心的信息(例如表、列、实体的状态等)时，我认为它就开始闻起来了。

Answer 2

对于复杂程度低到中等程度的应用程序，使用基本可持久化对象可以真正提高开发效率。

但是，这样做会限制您的代码，并随着应用程序变得更加复杂而限制设计选项。显然，在开始时使用完基类，这在C#和Java中很重要。它还助长了关切的分离程度不高。

我想说，在考虑任何ORM时，最重要的是问这些问题(来自Jeremy的文章工作模式的单位与坚持不懈的无知)：

• 业务逻辑能独立运行数据库吗？
• 我可以独立地从数据库模型设计我的领域模型吗？
• 我的持久性策略是如何影响我的业务逻辑的？

Answer 3

除非您使用数据传输对象(DTO)进行持久化并使用该模型，否则在我的经验中，为可持久化类设置一个根对象可以大大减少代码重复，并提高开发人员的工作效率。即使在使用DTO时，我也认为这是有帮助的，尽管我很少使用DTO，因此不能从经验中发言。

我不认为这是代码气味，原因如下：

1. 提高开发人员的生产力。
2. 将持久性代码合并到一个类中。
3. 很容易更改为实现相同方法的另一个框架(只需更改所有业务类的继承，并更新原始根类的检查)。

编辑:内联statichippo的答案，我同意他对这个基类的看法，包括关于底层数据存储机制的信息(如表/列名、数据库类型等)。