SRP声明类应该只做一件事，比如在存储库的情况下持久化实体。我猜你在这里混淆了“类”和“对象”：如果你有几个方法可以改变 object 的状态，这可能与SRP一致。然而，仓库 * 类 * 改变的唯一原因应该与它的目的有关，即在这种情况下持久化或检索实体。
Wikipedia上关于Single Responsibility Principle的文章说得很好。
关于你的第二点：一个类可以拥有的依赖项的最大数量是不存在的，但是如果依赖项太多，这可能是设计缺陷的标志。

单一责任原则（SRP）指出，一个类的改变不应该有一个以上的原因。
单一责任原则并不意味着组件/类的单一方法或单一类型的操作。
它意味着在一个问题的范围内的单一责任。
持久化操作也是同样的问题。
所以把它们放在一个类中并不违反必要性原则。
现在，如果你有一打又一打的特定数据库操作，那么将它们划分为不同的类是有意义的，这些类具有明确定义的职责，例如选择操作，更新操作等等。
通常我们的Resource、Service和Repository类都有create、read、update和delete方法。我们正在更改每个类以修改这些操作中任何一个的代码。是否违反了SRP？
这些是不同的层次。
如果您更改了一个层的模型，其他层通常会因为数据在层之间传递而受到影响。
这就像如果你在数据库中添加了一个信息，如果你想查看/操作它们，你必须改变你的GUI和处理。
现在，如果你改变层的实现，其他层应该没有或很少的后果。

• • 责任和功能**之间有区别。如果一个类只有一个函数，那么每个类只有一个公共方法。责任的界定至关重要。例如，如果我们有一个字符串操纵器类，它的职责是字符串操纵。它可以有多个函数- reverse、upperCase、LowerCase、truncate。所有与字符串操作相关的函数都可以是该类的一部分。但是如果我们尝试添加一个奇怪的功能，比如字符串转换或字符串打印，那将破坏SRP。所以，只要你的函数/方法在类的责任范围内，你就遵循SRP。