Question

我在一个大系统内有多个子系统。因此，每个子系统都拥有自己的BAL和DAL实现。现在BAL具有重要的逻辑，但DAL基本上具有相似的代码，因此我将其重构为一个通用DAL类，现在在所有子系统中使用。像这样：

让我们假设子系统名称为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必须注入通用DAL对象。所以现在BAL因为重构和DI要求而不必要地意识到泛型DAL对象，理想情况下它不应该（特别是在重构的情况下）。

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

那你们觉得怎么样？有没有人有更好的重构实现，其中DI，关注点的分离（即A的BAL只知道A的DAL而不是通用的DAL对象）和灵活性（对所有子系统具有不同的DAL）是完整的。

我想到的方法之一是在A和B的DAL中有2个构造函数，因此从BAL我们可以在不注入泛型DAL的情况下调用，并且从单元测试中我可以注入Generic DAL对象。

Answer 1

子系统A和B的DAL没有做任何事情所以我们应该摆脱它们并调用泛型DAL本身，但在我看来它会降低灵活性，因为明天AAL的DAL可能想要做一些记录或者一些B或甚至C可能不会订阅的其他特殊行动。

课程应为open for extension but closed to modification。这意味着添加日志记录并不意味着您需要更改A的DAL。您应该能够通过创建包装泛型DAL的装饰器来完成此操作。这同样适用于其他跨领域问题。

因此，这种灵活性不是IMO强有力的论据，可以保留额外的间接层。

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

1 个答案: