域/业务层的设计模式选择

Arpit Khandelwal

我试图避免此类ContentDomain成为God类,并将功能隔离为特定的类(以遵循SRP),如下所示

ContentDomain

 public class ContentDomain : IContentDomain
{
    private ISolutionDomain solutionDomain;
    private IServiceDomain serviceDomain;
    private IPhaseDomain phaseDomain;

    public ContentDomain(IUnitOfWork _unitOfWork)
    {
        this.solutionDomain = new SolutionDomain(_unitOfWork);
        this.serviceDomain = new ServiceDomain(_unitOfWork);
        this.phaseDomain = new PhaseDomain(_unitOfWork);
    }

    public ISolutionDomain SolutionDomain { get { return solutionDomain; } }
    public IServiceDomain ServiceDomain { get { return serviceDomain; } }
    public IPhaseDomain PhaseDomain { get { return phaseDomain; } }
}

特定领域类别之一

public class SolutionDomain : BaseDomain, ISolutionDomain
{
    public SolutionDomain(IUnitOfWork _unitOfWork)
        : base(_unitOfWork)
    {

    }

    public IEnumerable<Solution> GetAllSolutions()
    {
        return base.GetAll<Solution>(sol => sol.IsActive == true).OrderBy(rec => rec.Name).Select(rec => rec).ToList();
    }
}

现在,我的控制器仅了解ContentDomain并在需要时从SolutionDomain / ServiceDomain / PhaseDomain调用特定方法:

public ContentController(IContentDomain domain, ICurrentUser currentUser)
        : base(domain, currentUser)
    {

    }


public ActionResult Home()
    {
        var myServices = domain.ServiceDomain.GetServicesWithDetails(rec => rec.CreatedBy == currentUser.Name);
        var viewModelCollection = myServices.Select(service => new DashboardViewModel(service, domain));

        if (currentUser.IsInRole("SU"))
            return View("Home_SU", viewModelCollection);

        else if (currentUser.IsInRole("Reviewer"))
            return View("Home_Reviewer", viewModelCollection);

        else return View("Home", viewModelCollection);
    }

注意Home()中的第一条语句

domain.ServiceDomain.GetServicesWithDetails(rec => rec.CreatedBy == currentUser.Name);

我发现自己在ContentDomain类中混合了Facade和Composition。

现在的问题是-

  1. 使用合成通过Facade公开特定的域功能是否合理?
  2. 如果没有,那可能是什么呢?
  3. 我有可能违反这种方法的任何SOLID原则吗?
马克·西曼(Mark Seemann)

使用合成通过Facade公开特定的域功能是否合理?

根据示例,ContentDomain类和IContentDomain接口不提供任何功能。更好的组合形式是丢弃两者,并根据它们所需最小依赖集来定义Controller和其他客户端

private readonly IServiceDomain serviceDomain;
private readonly ICurrentUser currentUser;

public ServiceController(IServiceDomain serviceDomain, ICurrentUser currentUser)
{
    this.serviceDomain = serviceDomain;
    this.currentUser = currentUser;
}

public ActionResult Home()
{
    var myServices = this.serviceDomain.GetServicesWithDetails(
        rec => rec.CreatedBy == currentUser.Name);
    var viewModelCollection = myServices.Select(
        service => new DashboardViewModel(service, domain));

    if (this.currentUser.IsInRole("SU"))
        return View("Home_SU", viewModelCollection);

    else if (this.currentUser.IsInRole("Reviewer"))
        return View("Home_Reviewer", viewModelCollection);

    else return View("Home", viewModelCollection);
}

这是真实的成分,因为您撰写ServiceController与实现IServiceDomainICurrentUser

如果没有,那可能是什么呢?

IContentDomain的设计存在几个问题

  • 维护起来更加困难,因为每次您想向中添加另一项服务时IContentDomain,都需要将其作为(只读)属性添加到接口中,这是一项重大突破。
  • 它可能掩盖了比起立​​即显现的情况,存在更多的依赖关系。查看建议的的构造函数ServiceController,看起来好像只有两个依赖项传递给ServiceController,但是实际的数量是四个。扁平构造函数注入的一大好处是,它很清楚何时违反了单一职责原则
  • 它违反了接口隔离原则(见下文)。

我有可能违反这种方法的任何SOLID原则吗?

是的,此设计违反了SOLID,因为至少它违反了接口隔离原则,该原则规定不应强迫客户端依赖于不使用的成员

但是,在上面的示例中,尽管它不使用属性,但是它ServiceController被迫依赖于SolutionDomainPhaseDomain属性。

这种设计也很可能导致违反“单一责任”原则,因为您传递给客户端的功能越多,它倾向于自己做的事情就越多,而不是依赖于系统的其他部分。

也有可能会导致违反Liskov替代原则(LSP),因为通常的趋势是,您在接口上定义的成员越多,则遵守LSP的难度就越大。通常,报头接口往往会导致LSP违规。

本文收集自互联网,转载请注明来源。

如有侵权,请联系[email protected] 删除。

编辑于
0

我来说两句

0条评论
登录后参与评论

相关文章

来自分类Dev

域/业务层的设计模式选择

来自分类Dev

数据访问层的设计模式

来自分类Dev

设计模式:C ++抽象层

来自分类Dev

业务运营/工作流设计模式

来自分类Dev

如何选择设计模式

来自分类Dev

c#在域驱动设计中放置业务规则

来自分类Dev

数据整合层(ETL)的设计模式

来自分类Dev

验证库设计模式选择

来自分类Dev

基础架构层中的域驱动设计存储库实现

来自分类Dev

呼叫业务层方法

来自分类Dev

呼叫业务层方法

来自分类Dev

是否应该在ViewModel(UI层)和域Model(业务层)中使用相同的Enums定义?

来自分类Dev

数据库层中异常处理的设计模式

来自分类Dev

如何在业务逻辑层中使用单例和/或工厂模式

来自分类Dev

设计XAF业务对象

来自分类Dev

ActionResult选择器和设计模式

来自分类Dev

为我的规格选择设计模式

来自分类Dev

如何选择正确的架构/设计模式

来自分类Dev

由于设计不良的业务和数据库层,MVC4中出现极端性能问题

来自分类Dev

业务层呼叫业务层或直接呼叫DAO

来自分类Dev

业务层呼叫业务层或直接呼叫DAO

来自分类Dev

域驱动设计的聚合模式和@OneToMany单向休眠

来自分类Dev

域驱动设计的聚合模式和@OneToMany单向休眠

来自分类Dev

设计问题-Dot-Net 3层应用程序中的ORM与OOP-对象应自行保留还是仅业务逻辑层应调用DAL

来自分类Dev

使用存储库模式,我们应该为DAL中的每个表还是业务层中的对象定义类?

来自分类Dev

模型层中的域驱动设计数据库验证

来自分类Dev

gRPC和域驱动设计-在哪里放置原型文件(域层与其他地方)?

来自分类Dev

域对象中的业务逻辑

来自分类Dev

如何在设计模式下以编程方式选择控件

Related 相关文章

热门标签

归档