一个对象能够将自身保存到数据库中是否会破坏类的内聚性？
就面向对象设计而言，您认为将自身保存到数据库中的功能赋予对象会破坏类的凝聚力吗？
想象一下：
Product p = new Product()
{
Name = "Joy Rider",
Price = 100,
Currency = "USD"
};
您认为将此产品保存到数据库中是否最好以这种方式完成：
p.Save();
或者以类似这样的方式完成：
ProductServices.SaveProduct(p);
您认为怎么样？
Speaking in terms of object oriented design, do you think to give a functionality of saving itself into Data-base to an object spoils the COHESION of the class?
Imagine:
Product p = new Product()
{
Name = "Joy Rider",
Price = 100,
Currency = "USD"
};
Do you think to save this product p onto DataBase is better to be done in this way:
p.Save();
or in a way something like this:
ProductServices.SaveProduct(p);
What do you think?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
可以将自身保存到数据库的对象将违反 SRP（单一职责原则）。
持久性本身就是一种责任，应该由专门的类来处理。
这是除了具有低内聚性之外的情况 - 与持久性有关的成员与那些不涉及持久性的成员没有关系，也不会在不处理持久性的类的方法中使用。
An object that can save itself to the database would violate SRP (Single responsibility principle).
Persistence is a responsibility all by itself and should be handled by dedicated classes.
This would be in addition to having LOW cohesion - the members that have to do with persistence have no relation to those that do not and would not be used in those methods of the class that do not deal with persistence.
它确实干扰了单一责任原则。您的示例中的 Product 类的目的是表示一个产品以及对该产品的操作。与数据库交互不是该类职责的核心部分。
拥有 ProductServices 类可以提高代码的可维护性。假设在数据库中保存对象的逻辑要更改（这是可以的），您想要更改系统中的每个实体类吗？
It does interfere with the single responsibility principle. The purpose of the Product class in your example is to represent a Product and the operations on that product. Interacting with the database is not a core part of the class' responsibility.
Having the ProductServices class increases the maintainability of your code. Suppose the logic for saving objects in the database was to change (which it can) do you want to change every entity class in your system?
就面向对象设计而言，只有这样，Save 方法作为Product 的一部分才没有任何问题。它实际上是面向对象设计世界中的首选方法。从纯粹的面向对象的角度来看，您不希望它被分解，因为它比对象更具功能性。
但是，如果您相信依赖倒置原则，即高级模块不应依赖于低级模块；那么 Save 方法是合适的，但它应该采用抽象 Connection 类型作为参数。这将为您提供一个很好的对象模型，其中包括 Save 方法，但它不知道连接类型。
In terms of Object Oriented Design only then no there is nothing wrong with the Save method being part of Product. It would actually be the preferred method within the Object Oriented Design world. And from a pure OO perspective you would not want it broken apart because that's more functional than object.
However, if you believe in the Dependency Inversion Principle which says high level modules should not depend upon low level modules; then a Save method would be appropriate but it should take an abstract Connection type as a parameter. This would give you an nice object model which includes a Save method but it would have no knowledge of the type of connection.