分层依据(转)

提到“设计结构”，我们马上就会想到分层，像比较流行的三层结构：UI、业务、数据。那么我们为什么要分层，如果不清楚这个原因，我相信你可能一直在滥用分层。我看过我一些朋友的设计，大多数都采用的分层，可是他们所谓的几层结构从设计角度来看真的很糟糕，有些甚至在业务逻辑层里直接使用了MessageBox.Show方法和HttpContext.Current.Request等等！！我当时就反问他们，为什么要这样用？他们的回答我感到很吃惊，说是：“为了封装，如果业务层执行时发生了异常，再把异常抛给UI层，再有UI层去Show，这多啰嗦，而且影响性能”！大家试想，业务层要做的事情是啥？仅仅处理业务逻辑，它不负责显示（这样就可以被不同的使用者调用，如：WinForm、WebForm、WebService、WCF等等），而上面的那个MessageBox.Show很明显是上一层的东西，这就把业务层困死在了只能被WinForm使用，所得所失显而易见。当然，如果项目较小，开发过程容易控制，需求也相对稳定，如果我作为构架师，我肯定会很坚决的抛弃分层（要抛弃的连个影子都找不到），要它干吗？增加代码量吗？

说了这么多，我只是为了说明一句：分层是一种工具，我们要有选择的去使用，要分就要分得彻底！

我的分层依据跟大家共享交流一下：
1：抽象要到位，不要把所有的功能都堆到一起
2：封装要彻底，保证层次间接口的简单性
3：杜绝层次间的反向依赖和跨层次访问