能够将自身保存到DataBase中的对象是否会破坏类的Cohesion？

Question

就面向对象设计而言，您是否认为提供将数据库保存到对象的功能会破坏类的COHESION？

想象：

Product p = new Product() 
          {
           Name = "Joy Rider", 
           Price = 100, 
           Currency = "USD"
          };

您是否认为将此产品保存到DataBase最好以这种方式完成：

 p.Save();

或以某种方式：

 ProductServices.SaveProduct(p);

您怎么看？

Answer 1

可以将自己保存到数据库的对象会违反SRP（单一责任原则）。

持久性本身就是一种责任，应由专门的班级来处理。

除了具有低内聚力之外，与持久性有关的成员与那些没有持久性的成员没有任何关系，也不会在那些不处理持久性的类的方法中使用。

Answer 2

它确实干扰了单一责任原则。示例中Product类的用途是表示产品以及该产品上的操作。与数据库交互不是班级责任的核心部分。

使用ProductServices类可以提高代码的可维护性。假设在数据库中保存对象的逻辑是要更改（它可以）您想要更改系统中的每个实体类吗？

Answer 3

就面向对象的设计而言，只有产品中的Save方法没有任何问题。它实际上是面向对象设计世界中的首选方法。从纯粹的OO角度来看，你不希望它被分开，因为它比对象更有用。

但是，如果您相信依赖性倒置原则，即高级模块不应该依赖于低级模块;然后一个Save方法是合适的，但它应该采用抽象的Connection类型作为参数。这将为您提供一个很好的对象模型，其中包含一个Save方法，但它不知道连接的类型。