Question

我见过的以下类型的设计基本上都有“瘦”类，不包括任何类型的行为。辅助类用于插入/更新/删除/获取。

这是错的吗？它是反OOP吗？

User.cs

public class User
{

    public string Username { get; set; }
    public string Password { get; set; }
}


Users.cs


public class Users
{
    public static User LoadUser(int userID)
    {
            DBProvider db = new DBProvider();
            return dp.LoadUser(userID);

        }

}

Answer 1

虽然您的user.cs类适用于domain transfer object，但Users.cs类实际上是您可以在data-access objects中应用业务规则的地方。

您可能需要考虑类的命名约定以及命名空间。当我查看users.cs时，我假设它基本上是一个用于处理用户列表的类。

另一种选择是查看Active Record Pattern，它将组合您创建的两个类。

User.cs

public class User
{
    public string Username { get; set; }
    public string Password { get; set; }

    public User(int userID)
    {
        //data connection
        //get records
        this.Username = datarecord["username"];
        this.Password = datarecord["password"];
    }
}

Answer 2

我会将其归类为域对象或业务对象。这种设计的一个好处是它使模型不受任何业务逻辑的影响，并且可以在不同类型的环境中重复使用。

第二类可以归类为DAO（数据访问对象）。

这种模式根本不是反oop，而且被广泛使用。

Answer 3

我认为您正在实施domain model和data-access object。这是一个好主意。

Answer 4

第一个类是反OOP，因为它包含没有行为的数据，这是anemic domain model的典型示例。对于使用OO语言进行过程式编程的人来说，这是典型的。

然而，对于将数据库访问逻辑放入域模型本身（活动记录模式）还是像在代码中一样，将数据访问逻辑放入单独的类（数据访问对象模式）是否有意义，因为DB访问是一个单独的技术问题，不一定与领域模型紧密结合。

Answer 5

看起来它可能是repository pattern这似乎是一种越来越常见的模式，并且在Rob Conery's Storefront示例Asp.Net MVC应用程序中被用来产生很大影响。

您基本上是将数据访问代码从模型中抽象出来，这通常是一件好事。虽然我希望对模特课有点胆量。同样从之前的经验来看，称其为User令人困惑，UserRepository可能更糟糕。也可能想要考虑删除静态（这是一个热门的争论），但使模拟更容易。另外，存储库应该实现一个接口，这样你就可以模拟它，然后用假的替换它。

Answer 6

它在任何意义上都不是真正的面向对象，因为对象只不过是一堆数据粘在一起。这并不是一件可怕的事情。

您如何为类别分类这类设计？

6 个答案: