Question

我发现很难确定类的责任：我是否必须将此方法放在此类中，还是应该将此方法放在另一个类中？例如，假设一个带有id，forname，lastname和password的简单User类。现在你有了一个userId，你想要forname和lastname，所以你创建了一个方法，如：public User GetUserById（int id）{}。接下来，您要显示所有用户的列表，因此您创建另一个方法：public List GetAllUsers（）{}。并且您想要更新，删除和保存用户。这为我们提供了5种方法：

public bool SaveUser(User user);
public bool UpdateUser(User user);
public bool DeleteUser(User user);
public User GetUserById(int id);
public List<User> GetAllUsers();

所以我的问题是：你把所有这些方法放在User类中吗？或者您是否创建了另一个可以连接到数据库并包含所有这些方法的数据类（UserData类）？

Answer 1

您在此处描述的内容基本上是Active Record Pattern或Repository Pattern之间的选择。我建议您阅读这些模式，并选择适合您的应用程序/体验/工具集的模式。

Answer 2

我不会将这些特定方法放入“用户”类中。

这个'问题'有两种常见方法：

您将这些方法放在用户中上课，然后这意味着你使用Active Record模式
你把这些方法放在一个单独的类（UserRepository）实例，然后你正在使用 Repository模式。

我更喜欢存储库方法，因为它可以保持我的'User'类干净，并且不会使用数据访问代码使其混乱。

Answer 3

除非特定于一组用户的额外复杂性（或者真正精心设计的数据库访问机制），否则我可能会在User类上使这些方法保持静态。

Answer 4

这些方法对我来说听起来更像UserManager（或类似的东西）。用户类应该只对应并代表单个用户，而不是很多。

Answer 5

如果我们查看企业应用程序设计模式，那么获取用户的方法，即GetUserByID和GetAllUsers将在单独的类中 - 您可以将其命名为UserData或UserDAO（DAO - 数据访问对象）。

实际上，您应该为UserDAO设计一个接口，使用适当的方法来处理用户对象 - 例如CreateUser，UpdateUser，DeleterUser，GetUserXXX等。

根据数据源应该有UserDAO的实现，例如，如果您的用户存储在数据库中，那么您可以在UserDAO的实现中实现访问数据库的逻辑。

以下是将访问方法保持在单独的类中的优点：

1）用户对象应该只是getter setter方法的普通对象，这有利于跨层传递对象 - 从数据访问层到业务层到Web层。这也有助于保持用户对象可序列化

2）数据访问逻辑与User对象松散耦合 - 这意味着如果数据源发生更改，则无需更改User对象本身。这也有助于测试驱动开发，您可能需要在测试阶段使用模拟对象

3）如果User对象是与其他对象（如Address或Department或Role等）有关系的复杂对象，则关系的复杂性将封装在UserDAO中而不是泄漏到用户对象中。

4）如果遵循模式，移植到NHibernate或Spring.NET或.NET LINQ等框架会变得更容易

Answer 6

让我们看看你的情景。

贵公司的装配部门有'N'人。

可以去找一个人询问他的信息，但是你不能指望他告诉你所有在装配部门工作的人的详细信息。为什么他会记住所有细节的原因，如果你确实希望他的效率会下降（在集会上工作，还要记住其他人的细节）。

所以......也许我们可以任命一位能够做这个人力资源管理活动的经理（获取详细信息，添加新人，编辑，删除等）

因此你有两个实体

1）在您的装配部门工作的用户/人员 2）经理

因此有两个班级。希望这会对你有所帮助。

由于

Answer 7

在其他条件相同的情况下，两种方式都可以。但是，选择哪种方法通常取决于您在其中找到User类的应用程序或类库的整体架构。如果数据访问代码似乎与User目标代码纠缠在一起，那么将它分成两个类可能更有意义，如您所考虑的那样。如果CRUD方法是具有特定于应用程序的逻辑的DAL的单行委托，那么将它们留在User类中应该没问题。

在这两种情况下，复杂性或多或少相同 - 它是低维护组件与少量高维护级别之间的权衡，或者是具有大量低维护级别的高维护组件。“ p>

我还假设CRUD方法应该是static。

最简单的做法是立即编写代码，但如果你发现它会更好，那么考虑将来可能的重构。

Answer 8

如果我正确理解您的问题，则User类会处理单个用户。因此，用户类没有关于它们有多少用户或有关它们的任何信息的线索。保存此信息的结构位于其他位置，您提到的方法似乎属于该结构/类。

C＃类和方法

8 个答案: