您将这个 CRUD 类命名为什么？

Question

试图避免这里的 SomethingManager 陷阱......

假设我要编写一个用户编辑器，允许管理员在系统中创建用户。 非常基本的功能 - 查看现有用户列表、创建新用户、更新现有用户、删除用户。

我们还假设我决定编写一个“业务”类来处理这些基本的 CRUD 操作。 界面可能如下所示：

public interface ISomeUsefulName
{
    IList<User> FetchUsers();
    User FetchUser(int userId);
    bool SaveUser(User user);
    bool DeleteUser(int userId);
}

例如，在 SaveUser() 方法内，我将验证数据（使用不同的类），然后将数据实际保存到数据库（再次使用另一个类）。

我的问题是，我应该给这个类起什么名字？ 这个类做得太多了，因此我应该将其分成多个类吗？

Answer 1

如果不遵守 SRP，命名会很困难:)
但成员的命名经常被滥用。

在你的情况下，我会做这样的事情：

• 实施的责任是涵盖指定的持久性合同
• “谁”受到攻击

思考没有声音
- 为用户完成持久化，相关名称可以是 IUserRepository
- 方法不比CRUD多
- 因为 IUserRepository 是供用户使用的，所以没有必要有 UserSave、UserUpdate，因为它破坏了通用使用方式

魔法就在这里...只需这样做：

public interface IRepository<TYPE, KEY>{
  IList<TYPE> GetAll(KEY key);
  TYPE GetById(KEY key);
  void Save(TYPE obj);
  void Update(TYPE obj);
  void Delete(Key key);
}

很难吗？
定制一件该怎么办？

public interface IUserRepository : IRepository<User, int>
{
   IList<User> GetAllMyFavorites(ICriteria crit);
   IList<Events> GetHistoryByUser(User user);   
}

在使用 IoC 容器的代码中，你可以轻松祝

public UserController {
  private _userRepository = null;
  private _eventsRepository = null;

  public UserController(IUserRepository userRepository, 
  IRepository<Events,int> eventsRepository) 
  // if you are doing here just CRUD use the generic signature
  {
    _userRepository = userRepository;
    _eventsRepository = eventsRepository;
  }

  public MarkItAsGoldPartener(int userId){
     var user = userRepository.GetById(userId);
     user.PartnerType = PartnerTypes.Gold;
     userRepository.Save(user); // the user in member name is useless
     eventsRepository.Save(new Event(){Message = "The user" + UserId + "is golden" });
  }
} 

你好运:)

Answer 2

我赞同 ChrisW 的呼吁，将其命名为“User”。

每当您发现自己将相同的字符串放在几乎每个方法的名称中时，都应该将其从方法名称中删除并放入类名称中。

Answer 3

IUserRepository —— 如 Repository 模式中所示。

Answer 4

IUserRepository 或 IUserServices。

Answer 5

我的偏好是 IUserStorage 或 IUserStore

Answer 6

事实上，你在命名时遇到困难，这应该是一个巨大的危险信号，表明它是错误的。

单一职责原则（和接口隔离原则）在这里适用。 将其分解为您需要的各种操作。

public interface IUserList
{
    IList<User> FetchUsers();
}

public interface IUser
{
   User FetchUser(int userId);
}

public interface IUserStore
{
    bool SaveUser(User user);
    bool DeleteUser(int userId);
}

然后命名它们就变得更加简单，因为现在只有一个名称真正适用。 相信我，如果您是设计师，您的开发人员会喜欢您让事情变得易于理解和使用。

Answer 7

它可以成为一个通用接口。

ICrud<T> { }

或者受到 IUserStore 的启发。

IStore<T> { }

Answer 8

为什么不只是 IUserCRUD？
相对于“管理”，CRUD 有 10 种含义。

Answer 9

将其称为“Users”（或“AuthorizedUsers”或“CollectionOfUsers”）怎么样？

Answer 10

我会选择UserActions。 这描述了您想要执行的功能集； 它避免了将其称为集合的陷阱（因为它实际上不收集任何东西，只是检索集合）。

但我也会重新考虑以这种形式开设这门课。 看起来您正在尝试安装一个持久性管理器； 您是否希望以这种方式保留任何其他类型的对象？ 您能否提取任何可以派生到基类的通用功能？ 也许是“PersistenceManager”类或类似的类？ 然后，如果绝对有必要（我不确定是否有必要），您可以派生一个“UserPersistenceManager”，它可以单独对 User 对象进行操作。 （我认为这可能没有必要，因为您可能能够仅从 PersistenceManager 执行您需要的所有操作；不过，只有您的特定实现可以告诉您这一点。）