在这里试图避免SomethingManager 陷阱...
假设我要编写一个用户编辑器，它允许管理员在系统中创建用户。非常基本的功能 - 查看现有用户列表、创建新用户、更新现有用户、删除用户。
假设我决定编写一个“业务”类来处理这些基本的 CRUD 操作。界面大概是这样的：
public interface ISomeUsefulName
{
IList<User> FetchUsers();
User FetchUser(int userId);
bool SaveUser(User user);
bool DeleteUser(int userId);
}
例如，在 SaveUser() 方法中，我将验证数据（使用不同的类），然后将数据实际保存到数据库中（再次使用另一个类）。
我的问题是，我应该给这个类起什么名字？这个类是不是做得太多了，所以我应该把它分成多个类？
【问题讨论】：
如果不遵守 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" });
}
}
祝你好运:)
【讨论】：
我同意 ChrisW 的呼吁，将其命名为“用户”。
任何时候你发现自己在几乎每个方法的名称中都添加了相同的字符串，应该将它从方法名称中删除并放入类名中。
【讨论】：
IUserRepository -- 如Repository 模式。
【讨论】：
IUserRepository 或 IUserServices。
【讨论】：
我的偏好是 IUserStorage 或 IUserStore
【讨论】：
您在命名它时遇到困难的事实应该是一个巨大的危险信号，它是错误的。
单一职责原则（和接口隔离原则）适用于此。将其分解为您需要的各种操作。
public interface IUserList
{
IList<User> FetchUsers();
}
public interface IUser
{
User FetchUser(int userId);
}
public interface IUserStore
{
bool SaveUser(User user);
bool DeleteUser(int userId);
}
然后命名它们就变得更简单了，因为现在只有一个名称真正适用。相信我，如果你是一名设计师，你的开发者会喜欢你，因为你让事情变得易于理解和使用。
【讨论】：
它可以成为一个通用接口。
ICrud<T> { }
或受 IUserStore 启发。
IStore<T> { }
【讨论】：
为什么不只是 IUserCRUD？ 与“管理”相反，CRUD 有 10 个含义。
【讨论】：
称它为“用户”（或“AuthorizedUsers”或“CollectionOfUsers”）怎么样？
【讨论】：
我会选择UserActions。这描述了您想要执行的一组功能；它避免了将其称为集合的陷阱（因为它实际上并不收集任何东西，只是检索一个集合）。
但我也会重新考虑首先以这种形式开设这门课。看起来您要安装的是持久性管理器；是否还有其他类型的对象要以这种方式持久存在？你能提取任何可以派生到基类的通用功能吗？也许是“PersistenceManager”类之类的？然后，如果它是绝对必要的（我不确定它是否会），您可以派生一个“UserPersistenceManager”，它可以单独对用户对象进行操作。 （我认为这可能没有必要，因为您可以仅通过 PersistenceManager 执行所需的一切；不过，只有您的具体实现才能告诉您。）
【讨论】：