具有通用代码的多个类的重构实现（使用DI）

我在一个大系统中有多个子系统。所以每个子系统都有自己的BAL和DAL实施。现在，BAL具有重要的逻辑，但DAL基本上具有相似的代码，因此我将它重构为一个通用的DAL类，该类现在用于所有子系统。事情是这样的：具有通用代码的多个类的重构实现（使用DI）

假设子系统名称为A和B

public class DalA 
{ 
    private IGenericDal genericDal; 

    public DalA(IGenericDal injectedGenericDal) 
    { 
     this.genericDal = injectedGenericDal; 
    } 

    public bool DoSomeDBWorkForA() 
    { 
     return genericDal.CommonDalMethod(); 
    } 
} 


public class DalB 
{ 
    private IGenericDal genericDal; 

    public DalB(IGenericDal injectedGenericDal) 
    { 
     this.genericDal = injectedGenericDal; 
    } 

    public bool DoSomeDBWorkForB() 
    { 
     return genericDal.CommonDalMethod(); 
    } 
}

现在注入通用DAL的DI部分是从视功能单元测试点很重要，所以BAL（S）必须注入通用DAL对象。因此，现在BAL不必要地意识到通用DAL对象，仅仅是因为重构和DI需求，理想情况下它不应该是（特别是在重构的情况下）。

另外我的一位朋友指出，子系统A和B的DAL（s）没有做任何事情，所以我们应该摆脱它们并调用通用DAL本身，但在我看来，它降低了灵活性，因为明天的DAL A可能想要做一些日志记录或其他一些B甚至C可能不会订阅的特殊操作。

那么你们怎么看？在DI，关注点分离（即BAL的A只知道A的DAL而不是通用的DAL对象）和灵活性（对于所有子系统具有不同的DAL）完好无缺的情况下，任何人都有更好的重构实现。

我想到的方法之一是在A和B的DAL中有2个构造函数，所以从BAL我们可以调用而不注入通用DAL，并且从单元测试我可以注入通用DAL对象。

来源

2017-01-03 Rachit Pandey

恕我直言，这是错误的，有一个系统（解决方案）的有系统的所有部件内的多个子系统。使用微服务是更好的主意，或将子系统更改为模块;）。 –

@ shA.t这是一个很好的建议，但在这种情况下，我不能承受由于微服务实现而导致的延迟增加;）那么在那种情况下，你会提出什么建议？ –

子系统A和B都在做什么，所以我们也许应该摆脱他们，并调用通用DAL本身的DAL（一个或多个），但在我看来，这降低了灵活性为A的明天DAL可能想要做一些日志记录或B甚至C可能不会订阅的其他特殊行动。

类应该是open for extension but closed to modification。这意味着添加日志记录并不意味着您需要更改A的DAL。您应该可以通过创建包装通用DAL的装饰器来完成此操作。其他交叉担忧也是一样。

所以这种灵活性是不是IMO保持间接的额外层的一个有力的论据

来源

2017-01-03 09:23:22 Steven

所以你说删除中间的DAL（s）暂时是要走的路，修改应该通过装饰器来处理，但是你不认为DAL（s）在世界上很少处理太多的逻辑更广泛的意义不应该总是（或者至少经常）以这种方式设计DAL，因为大多数应用程序有多个模块（因此多个DAL）需要处理？ –

@RachitPandey：是的，考虑到提供的信息，我建议删除中间层。我无法评论“全球DAL”是如何设计的，因为这里有太多共同的口味。 – Steven

我同意现在删除中间层，但会有一个异常，我希望你的想法。如果我直接从BAL调用通用DAL，那么我确实需要提供一些“DAL特定参数”，如SP名称等，我认为BAL不应该真正意识到这一点。此外，我无法从通用DAL中删除这些参数，以使其保持通用。 –

具有通用代码的多个类的重构实现（使用DI）

回答

相关问题