在我开始发牢骚之前，这是我的观点概括：所有的东西都必须合在一起......然后一条河流贯穿其中。
编程让我感到困扰。
=======
贫血数据模型和我... 嗯，我们很亲近。也许这只是小型到中型应用程序的本质，几乎没有业务逻辑内置其中。也许我有点“智障”。
然而，这是我的两分钱：
你难道不能将实体中的代码因素分解出来，并将其绑定到接口上吗？
public class Object1
{
public string Property1 { get; set; }
public string Property2 { get; set; }
private IAction1 action1;
public Object1(IAction1 action1)
{
this.action1 = action1;
}
public void DoAction1()
{
action1.Do(Property1);
}
}
public interface IAction1
{
void Do(string input1);
}
这是否会违反SRP的原则？
此外，拥有一堆仅被消费代码联系的类实际上是对SRP更大的违反，只是把它们推到了另一个层次。
想象一下编写客户端代码的人坐在那里试图弄清楚与 Object1 相关的事情。如果他必须使用你的模型，他将与 Object1、数据包以及许多具有单个职责的“服务”一起工作。他的任务就是确保所有这些东西正确地交互。所以现在他的代码变成了一个事务脚本，而该脚本本身将包含完成特定事务（或工作单位）所需的所有职责。
此外，你可能会说，“不用担心，他只需要访问服务层。就像 Object1Service.DoActionX(Object1)。小菜一碟。”好吧，那么逻辑在哪里呢？全部都在那个方法中？你仍然只是在推动代码，并且无论如何，你最终都会将数据和逻辑分离。
因此，在这种情况下，为什么不向客户端代码公开特定的 Object1Service，并使其 DoActionX() 基本上成为领域模型的另一个钩子呢？我的意思是：
public class Object1Service
{
private Object1Repository repository;
public Object1Service(Object1Repository repository)
{
this.repository = repository;
}
public void DoAction1(Object1DTO object1DTO)
{
Object1 object1 = repository.GetById(object1DTO.Id);
object1.DoAction1();
repository.Save(object1);
}
}
你已经将Action1的实际代码从Object1中分离出来，但在所有情况下，你拥有了一个非贫血的Object1。
假设你需要Action1来表示2个（或更多）不同的操作，你希望将它们原子化并分别放入自己的类中。只需为每个原子操作创建一个接口，并在DoAction1内部连接即可。
这就是我处理这种情况的方式。但话说回来，我真的不知道SRP是什么。
