单一职责原则和存储库答案

【问题标题】：Single responsability Principle and Repository单一职责原则和存储库
【发布时间】：2014-11-02 17:34:06
【问题描述】：

尽管在谷歌上搜索了很多，但我找不到明确的答案来解决我的疑问。

我正在尝试尽可能应用“SOLID”，并尝试使用常识并在我看到一个模式造成的问题多于它试图解决的问题时避免使用该模式。我不想应用一个模式来创造生活如果你明白我的意思的话，其他人很难仅仅为了“我编写模式”而使用我的代码..

现在我正在努力解决我认为最容易掌握“SRP”的原则之一

您如何将这些原则实际应用于存储库？

假设我有一个

通常他们会有像论文这样的方法

public interface IUserRepository
{
    User GetUser(int id);
    IEnumerable<User> GetAllUser();
    void DeleteUser(int id);
}

员工和产品也是如此。

我们是说这些方法中的每一个都应该是一个独立的类吗？即使有时我们只讨论一行代码？

任何地方的任何建议或示例应用程序都将不胜感激。

非常感谢

【问题讨论】：

【解决方案1】：

如果您很难弄清楚单一职责模式的限制，那么您可以寻找不使用 SRP 的类的明显示例。例如，一个为用户实现业务规则以及配置用户数据库备份的类，顺便说一下，它还公开了一些特殊的日志记录到文件中，因为它是一个相当巧妙的 hack。你绝对应该避免这种情况。

您似乎能够一直应用 SRP 以便每个方法都可以放在单独的类中的原因之一可能是因为您有一个 贫血域模型。也许您的应用程序只是在数据库之上公开了 CRUD 操作，而您的应用程序中没有实现真正的业务规则？

在任何情况下，它都没有应用 SRP 将 UserRepository 拆分为每个方法的类，但你甚至得到这个想法可能表明 UserRepository 在你的架构中没有任何用途。

【讨论】：

【解决方案2】：

对于基本的 CRUD 操作，通常使用通用存储库：

public interface IRepository<T>
{
   T Get(int id);
   IEnumerable<T> GetAll();
   T Update(T item)
   void Delete(int id);
}

或类似的。然后你的具体实现可以从一个基础继承。

【讨论】：

【解决方案3】：

这可能取决于抽象级别。

//具有某些行为的对象：持久性模型+行为 Class Cat { string Name {get;set;} void Meov(){...} }

//具有某些行为的对象

SomeRepository:ISomeRepository{
User GetUser(int id);
IEnumerable<User> GetAllUser();
void DeleteUser(int id);

}

【讨论】：

【解决方案4】：

我想说这取决于您在哪里设置“单一职责”的范围。在我看来，你可以这样说：

每个存储库只负责管理一种类型的实体。这意味着UserRepository 中的所有方法都应与User 实体相关，但与其他实体（如产品）不相关。这意味着您的 UserRepository 中不应有任何方法，例如 GetProducts 或类似的东西。
存储库中的每个方法也应该有其单一的职责。这意味着每个方法都应该只处理一种特定情况（如创建、删除等）。

这样，您仍然可以满足 SRP 原则（取决于其周围的上下文），而不必为每个函数创建一个类（在我看来这似乎有点矫枉过正）。

【讨论】：