关于多层架构，引用后再继承的问题

Question

BLL层引用DAL层，并且BLL层的ClassBLL继承DAL层的ClassDAL，然后在控制台中只引用BLL层，提示出错了，不明白为什么会出这样的错误，我怎么才能使BLL的类继承了DAL的类，其它项目只需要引用BLL层就可以使用全部的东西，如图：

Answer 1

不想DAL被到处引用，只希望用到DAL的时候，引用BLL就行了

Answer 2

其实ConsoleApplication1项目已经添加了对BLL的引用了，但提示未对DAL的引用，DAL已经被BLL引用并且继承了，就是不想DAL到处被引用，才打算这么做，谁知道会有问题

Answer 3

问题出在于你的BLL层继承了DAL层的类。我们在做多层架构的原因就是能够使你的逻辑完全与数据层分开，也就是说假如将来你的数据层使用了不同的数据库而你的程序也不受影响，秩序重写数据层即可。而BLL继承了DAL的做法则使你的逻辑层和数据层不可分割的联系在一起。这样就使多层架构失去了意义。修改的方法是修改你的BLL的类来继承一个逻辑层的类，或把当前DAL层的这个类挪到BLL层。两种方法，目的都是为了使逻辑层不再继承数据层。

Answer 4

检查一下所有工程的属性中设置的 .net 平台版本是否一致。

Answer 5

暴露出来的另一个问题：继承并不是你这种概念，你这是滥用继承的。所谓继承，在逻辑上就是一种 is-a 关系，而非 has-a 关系。你的 BLL 只是组合 DAL，为什么设计为 继承呢？组合与继承都能间接引用 DAL 工程，关键是这不是技术问题而是设计问题。假设你因为“一个人有两个孩子”于是就说“这个人就是他自己的孩子、他的孩子就是他自己”，那岂不是神经错乱之后才会有的诡异逻辑？基于这种滥用继承的方式，你后边的代码就会越来越诡异。为了掩盖混乱，你会使用更多高大上的混乱技术名词儿，越来越乱。不要滥用继承。在根本不是继承关系时，就不能使用继承。使用继承的原则是基于业务逻辑上的“自然”的关系，绝不是什么“为了复用代码而继承”。为了复用什么 Open() 代码，那么你脑子中还真的有三层概念吗？还真的有分层概念吗？你认为一个 BAL 对象“就是”一个 DAL 对象，那么你满脑子就只有底层的增删改查而根本没有业务逻辑层概念了。

Answer 6

假设你在 BLL 层也没有什么真正的研究，就是一个简单的 Open 方法要提供服务，例如public class ClassBLL
{
    public void Open()
    {
         ClassDAL x = new ClassDAL();
        x.Open();
    }
}
它也是如此的组合写法。因为 BLL 中的 Open，是面向业务服务的，它可能组合许多功能代码，根本不是等价于“一个”数据库 Open 操作。可以说，你看不到 BLL，满脑子只有 DAL。你不去分析一个业务逻辑层该如何提供服务接口，安全没有心思去考虑 BLL 层设计。BLL 层为什么要有一个 Open 方法？有什么业务意义？在回答这个问题时，首先要忘掉数据库，用业务逻辑的概念来说明。例如假设我们要实时地将用户从手机上修改的笔记内容立刻持久化到系统服务器上，这个业务逻辑中可能会有“声明打开一个会话”的业务逻辑概念！但是，此时用什么数据库、用了几个数据库，除了数据库以外还有没有用到其它SOA服务，是不是调用电冰箱的编程接口去存取数据，这些都隐藏在 BLL层之下。因此 BLL 层的 Open（就算有的话）它就是从前端来说明的。如果你满脑子只有最底层的概念，终究无所作为。软件的设计是从前端出发的。不要太技术化了。