如何避免贫血领域模型，且避免将数据访问类放在领域类中？

Question

我正在尝试将业务逻辑从服务类和控制器中剥离出来，放到我的业务类中。

public interface IFoo{
  IBar CreateBar(creationParameters);
}
public class FirstFoo : IFoo{
  IBar CreateBar(creationParameters){
    return new FirstBar(creationParameter.Id);
  }
}
public interface IBar{
  void DoSomething();
}
public class FirstBar : IBar{
  FirstBar(int id){...}
  void DoSomething(){
    //well... do something
  }
}
public class SecondBar : IBar{
  FirstBar(int id){...}
  void DoSomething(){
    //well... do something else
  }
}

假设我需要创建一个 SecondFoo，并需要访问数据库以知道是否必须创建 FirstBar 或 SecondBar，我该如何做？我是否应该在 SecondFoo 的构造函数中注入数据源？或者使用服务定位器？或者将 createBar 方法移出 IFoo 接口？

编辑：我并不是在寻找“工厂模式”的定义，createBar 方法可能类似于“changeBar”或“doBusinessWithBar”。

- remi bourgarel

Answer 1

假设我需要创建一个名为SecondFoo的类，该类需要访问数据库来判断是创建FirstBar还是SecondBar。似乎SecondFoo需要某种决策逻辑来决定创建FirstBar还是SecondBar。这个逻辑可以分解为一个策略接口，其中数据库访问实现将用于生产环境。你可以通过构造函数注入该策略。

IBar CreateBar(creationParameters) {
  if (strategy.ShouldCreateFirst(creationParameters)) {
    return new FirstBar(creationParameter.Id);     
  }  
  else {
    return new SecondBar(creationParameter.Id);     
  }
}

- Jordão

---

这看起来很好，但如果我们滥用这种模式，最终会导致贫血的领域模型，对吧？ - remi bourgarel

并不一定。理想情况下，策略应该是领域的一部分，就像这个例子中的TaxEligibilityCheck一样。 - Jordão