我记得当MS发布一个论坛示例应用程序时，该应用程序的设计是这样的：

/Classes/User.cs
/Classes/Post.cs
...
/Users.cs
/Posts.cs

所以classes文件夹只有类，即属性和getters / setters。
Users.cs，Post.cs等具有访问数据访问层的实际方法，因此Posts.cs可能类似于：

public class Posts
{
    public static Post GetPostByID(int postID)
    {
          SqlDataProvider dp = new SqlDataProvider();
          return dp.GetPostByID(postID);
    }
}

另一种更传统的方法是将Posts.cs中的所有方法也都放入类定义(Post.cs)中。

将内容拆分为2个文件会使其更具程序性，不是吗？
这是不是违反了OOP规则，因为它将行为从类中移出并放入了另一个类定义中？

解决方案

回答

我们确定这些类不是局部类。在这种情况下，它们实际上不是两个类，而是一个类分散在多个文件中，以提高可读性。

回答

根据代码段，Posts主要是一类静态帮助器方法。 Post与Post是不同的对象。可以使用PostManager或者PostHelper来代替Posts。如果我们以这种方式考虑，则可能有助于我们理解为什么他们以这种方式爆发。

回答

对于应用程序去耦(或者松散耦合)，这也是重要的一步。

回答

什么是anti-OOP或者pro-OOP，完全取决于软件的功能以及使其工作所需的条件。

回答

如果每个方法只是直接调用数据源的静态调用，则" Posts"类实际上是一个Factory。我们当然可以将" Posts"中的静态方法放入" Post"类中​​(这是CSLA的工作方式)，但是它们仍然是工厂方法。

我会说" Posts"类的一个更现代，更准确的名称将是" PostFactory"(假设它所拥有的只是静态方法)。

我想我不一定会说这是一种"过程式"方法-这只是一个误导性的名称，我们会认为在现代OO世界中，" Posts"对象将是有状态的，并提供了操作和管理"发布"对象。

回答

好吧，这取决于在何处以及如何定义关注点分离。如果将代码填充到Post类中，则业务层将插入数据访问代码，反之亦然。

对我来说，在实际的域对象外部进行数据提取和填充是有意义的，并让域对象负责使用数据。