代码之家  ›  专栏  ›  技术社区  ›  Beep beep

事务脚本类型过程中的许多IOC依赖性——我们做错了什么?

  •  0
  • Beep beep  · 技术社区  · 14 年前

    我们有许多长期运行的过程,每个过程都需要几十个步骤。每一步都是相对复杂的,所以我们将这些步骤分成了自己的类。我们正在使用DI/IOC(结构图)来帮助我们使整个过程可测试。这一直很有效,但我们发现自己在控制类中有大量的依赖项。

    例如,在我们的大型例程中,处理客户机401K文件上载。这有近70个离散步骤。每个逻辑步骤组都属于自己的类,总共14个。其中每一个都非常小且易于管理,但是组织整个事件的类具有大量依赖性(即,我们有许多上帝类):

        public Client401kProcessor (IValidator uploadValidator, 
            IGeneralLedgerExporter glExporter, 
            IDataMapper dataMapper,
            IFinanceRepository financeRep,
            //...9 more
            IClientFileAuditor auditor)
        {
            _uploadValidator = uploadValidator;
            //... etc
        }
    

    这个特定的类只有几个公共函数,因此非常容易使用:

        public void ProcessClientFile(Guid savedFileId)
        {
            var clientUpload = _financeRep.FetchClientFile(savedFileId);
            _uploadValidator.Validate(clientUpload);
            _dataMapper.MapToStagedArea(clientUpload);
            _dataMapper.FlagAsStaged(clientUpload.Id);
            //...
            _auditor.RecordChanges(client.Id);
        }
    

    我觉得我们一定错过了什么。测试、理解和编写上述代码非常简单…但是.NET人员一直在告诉我们,我们有太多的依赖关系。我们如何减少这些依赖性,并使代码易于测试/维护?

    1 回复  |  直到 14 年前
        1
  •  1
  •   PHeiberg    14 年前

    正如阿伦在他的评论中所说,您可以引入一个聚合服务——一个负责协调一组依赖关系的中间人。在这样做之前,您必须问自己的第一个问题是,具有所有这些依赖性的类的职责是什么。它真的有单一的责任吗?

    读杰弗里·巴勒莫的书 blog post 关于“构造函数过度注入”代码的气味和跟踪 discussions 以及 follow up posts 它引起的。马克·西曼发表了几篇后续报道,包括 "Refactoring to Aggregate Services" 这是一个很好的读物。

    在您的特定情况下,processClientfile方法可能被提取到一个clientFileProcessor类中,或者如果文件处理由几个具有谨慎职责的逻辑步骤组成,则可以提取几个类。