关于单一责任原则，以及关于过大类的无处不在的警告，这些如何适用于实体类？从本质上来说，实体是不是应该封装一起实体的所有内容？这不是他们的“单一责任”吗？
否则，假设您的实体类变得“太大”，就像有人可能会说的那样，如果不破坏该实体应该提供的自然封装，您将如何实际解决这个问题？如果你有一个Person类，只有一个名字，年龄和喜欢的食物，那么显然它们都应该是Person的属性。但是，如果你需要添加20个类似的属性，比如眼睛颜色，isRightHanded，ReligionOfChoice等，该怎么办？仅仅因为它们中有很多，这突然意味着它们需要分成不同的类吗？对于“Properties1To5”和“Properties6To10”有一个单独的类，然后用这些类组成Person类似乎很愚蠢？
或者更正确的是，在Person类中直接保留100个属性（理论上可能彼此无关，除了它们属于Person的事实），因为Person类的单个职责是封装关于一个人的一切？
答案 0 :(得分：1)
如果你看一些编码标准文档，你可能会遇到“类应该不大于'x'方法”的论点。这些“标准”存在于良好的信仰中，但没有多大用处。我们的想法是阻止开发人员创建8000行，单片，适合所有类。我知道，我以前见过它，这很可怕。但是，限制“每个类的方法数量”，或者在您的示例中，“每个POCO的数量”可能会使事情变得模糊不清。
的确，以“每个类不超过30个方法”为例（比如，什么？），你最终会得到碎片化的类，由于30个方法的限制而被分割为纯粹的。这实际上使事情更糟。
类应该与需要一样大。这实际上取决于您的应用程序的设计和要求。我真正需要了解一个人，以及在我的要求范围内重要的内容是什么？如果我需要100个属性，并且业务规则有 defacto 需要记录这些属性中的每一个 - 并且它们用于报告和/或业务逻辑，那么它是有意义的你的人有100个属性。将它们拆分成块只会混淆数据，混淆代码，并使事情成为一场噩梦。
那就是，有时您可能想要将某些特征拆分到与我们的主人POCO相关的其他类中。你提到宗教是一种属性，也许在商业应用中它是必要的。但是，如果您的申请要点是弄清楚人们如何随着时间的推移改变他们的宗教信仰，那么它成为Person的一部分是没有意义的吗？我们现在突然有一个ReligionInstance POCO，它记录了他们在特定时间点的信念。我相信你可以看到我要去哪里，因为我确信其他100个属性 - 取决于项目的需要 - 其他人可能被分隔到他们自己的对象，因为这就是逻辑需求。例如，可以轻松添加地址所需的7/8字段。听起来不错，美观又轻松。 然而，如果此人移动，我们没有记录他们之前的位置。突然地址看起来像是一个很好的候选者，可以移动到他们自己的对象，并链接回的人，如果我们关心他们移动。
当你提到作曲时，我会以同样的方式思考 - 因为你想要创建的对象是其他信息的复合。如果我们想象我们存储Person并且我们还存储了1个或更多Address个POCO ..取决于业务逻辑，我可能只想要那个人，或者我可能想要他们和< / em>他们的地址。
这就是我所说的合成。我们的数据库有Person和Address，我们有一个名为PersonWithAddresses的非数据库POCO（例如），它会向我们提供此人的信息及其所有地址。业务规则定义了这些对象，我认为PersonWithAddresses是一个复合。
现在就是这个，什么存储库处理这个？我们可能有PersonRepository和AddressRepository，他们都对自己的个人POCO负责。我们还有一个CompositePerson存储库，使用这两个存储库构建一个更重量级的POCO，它拥有我们需要的所有信息吗？我们遵守单一责任模式。我们在需要的时候保持轻量级，而且没有什么比它应该做的更多