实体数据库方法

Question

我正在开始一个新的项目，关于将对象写入数据库的正确方法存在一些内部争论。

CRUD操作需要3个参数: DB句柄、DB名称、集合名称。

所有对象都是从BaseEntity对象(具有标准Id、创建时间、更新时间等)派生的。

第一种方法是将CRUD操作放在BaseEntity类中。所以你可以：

var obj = new MyObject() { ... }
obj.Insert(DB, DBName, CollectionName);

第二种方法是创建一个控制CRUD操作的类：

var collection = new Collection(DB, DBName, CollectionName);
var obj = new MyObject() { ... };
collection.Insert(obj);

我有我喜欢的方法(不是说哪个)，但是每个解决方案的一些可能的优缺点是什么？

使用中的语言是C#，但我认为这并不重要。

Answer 1

假设MyObject是某个表示域中某些概念的模型类，那么关注点的分离意味着数据库逻辑应该分开处理--导致一个单独的集合或存储库对象。这个解决方案似乎也要方便得多，因为现在我不必到处传递单独的DB/DbName/CollectionName对象。

另请参阅：

• 单一责任原则，
• 内聚力(如果相同的代码负责不同的事情，这就不是很有凝聚力)
• 耦合(如果模型类负责数据库逻辑，则耦合到数据库的接口)

然而，这两种解决方案都可以说是很好的。与选择稍微好的解决方案相比，更重要的是在您的代码库和生态系统中保持一致。许多成功的项目使用ActiveRecord风格的方法，其中域模型负责其自身的持久性，这也是非常好的。

特别是，对于所有对象来说，通常都需要串行化或持久化这样的交叉关注点。这种关注的“单一责任”可以用任何一种方式来论证:如果对象对其自身的持久性负责，那么与该对象相关的所有功能都可以很好地分组到一个内聚类中。或者:如果一个单独的存储库对象负责类的持久化，那么所有的持久性逻辑都很好地分组到一个内聚类中。

在这些备选方案之间的选择往往是武断的，但并非总是武断的。预期会发生变化的东西应该组合在一起。如果您可能添加新类或更改单个类的持久化方式，那么将持久化逻辑保留在类中似乎是明智的。相反，如果您更有可能更改持久化机制(例如切换到完全不同的数据库)，那么使用存储库模式似乎更明智。但是，当所有这些类都是同一个项目/解决方案的一部分时，它们就会被有效地分组--过于细粒度的视图并不总是有帮助的。