通过对象本身的方法还是通过另一个类保存对象？

如果要保存和检索对象，是否应该创建另一个类来处理该对象，还是最好在该类本身中进行处理？还是混合两者？

根据OOD范式推荐哪个？

例如

Class Student
{
    public string Name {set; get;}
    ....
    public bool Save()
    {
        SqlConnection con = ...
        // Save the class in the db
    }
    public bool Retrieve()
    {
         // search the db for the student and fill the attributes
    }
    public List<Student> RetrieveAllStudents()
    {
         // this is such a method I have most problem with it 
         // that an object returns an array of objects of its own class!
    }
}

与。（我知道以下内容是推荐的，但是在我看来，这与Student阶级的凝聚力有些矛盾）

Class Student { /* */ }
Class DB {
  public bool AddStudent(Student s)
  {

  }
  public Student RetrieveStudent(Criteria)
  {
  } 
  public List<Student> RetrieveAllStudents()
  {
  }
}

如何混合它们？

   Class Student
    {
        public string Name {set; get;}
        ....
        public bool Save()
        {
            /// do some business logic!
            db.AddStudent(this);
        }
        public bool Retrieve()
        {
             // build the criteria 
             db.RetrieveStudent(criteria);
             // fill the attributes
        }
    }

单一责任原则，关注点分离与功能凝聚力。如果您阅读了这些概念，那么您得到的答案是：将它们分开。

Student将“ DB”类与“ DB”类分开（或StudentRepository遵循更流行的约定）的简单原因是，您可以更改Student类中存在的“业务规则” ，而不会影响负责持久性的代码，反之亦然。反之亦然。

这种隔离非常重要，不仅在业务规则和持久性之间，而且在系统的许多方面之间，都可以使您以对不相关的模块产生最小影响的方式进行更改（这是最小的，因为有时是不可避免的）。它有助于构建更健壮的系统，在不断变化的情况下更易于维护且更可靠。

通过将业务规则和持久性混合在一起，或者像第一个示例中那样使用单个类，或者将其DB作为的依赖项Student，就可以将两个非常不同的关注点耦合在一起。看起来他们像是在一起的。它们似乎具有凝聚力，因为它们使用相同的数据。但这就是问题：内聚性不能仅由过程之间共享的数据来衡量，您还必须考虑它们所存在的抽象级别。实际上，理想的凝聚力类型描述为：

功能凝聚是指将模块的各个部分归为一组，因为它们都有助于完成模块的单个明确定义的任务。

显然，执行验证Student并保留一段时间不会形成“单个定义明确的任务”。同样，业务规则和持久性机制是系统的两个非常不同的方面，根据良好的面向对象设计的许多原则，应将它们分开。

我建议阅读有关Clean Architecture的文章，观看有关单一责任原则的讨论（使用了非常相似的示例），以及阅读有关Clean Architecture的讨论。这些概念概述了这种分离的原因。

两种方法都违反了单一责任原则。您的第一个版本将Student类赋予许多职责，并将其与特定的数据库访问技术联系在一起。第二个导致了一个庞大的DB类，它将不仅对学生负责，而且对程序中的任何其他类型的数据对象负责。编辑：您的第三种方法是最糟糕的，因为它在DB类和Student该类之间创建了循环依赖关系。

因此，如果您不打算编写玩具程序，请不要使用它们。相反，StudentRepository假设您将要自行实现CRUD代码，请使用不同的类（例如）来提供用于加载和保存的API。您可能还考虑使用ORM框架，该框架可以为您完成艰苦的工作（并且该框架通常会强制执行一些必须放置Load和Save操作的决策）。

有很多模式可用于数据持久性。有工作单元模式，有存储库模式，还有一些可以使用的其他模式，例如远程外观，等等。

其中大多数都有他们的粉丝和批评家。通常，要选择最适合应用程序的内容并坚持使用（所有方面都有其优点和缺点，即不要同时使用这两种模式……除非您真的很确定）。

附带说明：在您的示例RetrieveStudent中，AddStudent应该是静态方法（因为它们与实例无关）。

具有类内保存/加载方法的另一种方法是：

class Animal{
    public string Name {get; set;}
    public void Save(){...}
    public static Animal Load(string name){....}
    public static string[] GetAllNames(){...} // if you just want to list them
    public static Animal[] GetAllAnimals(){...} // if you actually need to retrieve them all
}

就我个人而言，我只会在相当小的应用程序中使用这种方法，可能是用于个人使用的工具，或者可以可靠地预测到我不会有比保存或加载对象更复杂的用例的应用程序。

另外，个人而言，请参见工作单位模式。当您了解它时，无论大小，它都很好。它得到了许多框架/ API的支持，例如，命名为EntityFramework或RavenDB。

如果这是一个非常简单的应用程序，其中对象或多或少地与数据存储区绑定，反之亦然（即，可以将其视为数据存储区的属性），那么对该类使用.save（）方法可能很有意义。

但是我认为那将是非常例外的。

相反，通常最好让类管理其数据和功能（如良好的OO公民），并将持久性机制外部化到另一个类或一组类。

另一个选择是使用一个持久性框架，该框架以声明的方式定义持久性（例如带有批注），但是仍然在外部化持久性。

• 在该类上定义一个对对象进行序列化的方法，并返回可以放入数据库或文件或任何其他内容的字节序列
• 具有该对象的构造函数，该构造函数将字节序列作为输入

关于这种RetrieveAllStudents()方法，您的感觉是正确的，确实可能放错了位置，因为您可能有多个不同的学生列表。为什么不简单地将列表保留在Student课堂之外呢？