近来对架构这块又有了新认识, MVC 也好, 三层也罢, 都是结构性模式, 由于结构化, 而可能忽视了行为事件, 这类的架构大多是一种 "失血"、"贫血" 模式 (这段话不理解先看完下面的分析, 再看下最后的小结, 然后回过头来理解这段话).

现在, 我更推荐领域驱动设计配合六边形架构 (领域驱动设计继承了职责驱动设计, 或者可以说是职责驱动设计的进化).

推荐本书: UML 和模式应用, 这本书介绍了对象职责的分配原则

参考资料:

对象的责任与职责

DCI 架构是什么？

如何从职责和协作中发现丰富对象？

MVC 模式已死

分享我对领域驱动设计 (DDD) 的学习成果

别在领域模型迷失了自己

三层

三层是从整个应用程序架构的角度来分的三层 (如果程序需要, 还可以分多层).

三层是为了解决整个应用程序中各个业务操作过程中不同阶段的代码封装的问题, 为了使程序员更加专注的处理某阶段的业务逻辑.

比如将数据库操作代码封装到一层中, 提供一些方法根据参数直接返回用户需要的相应数据, 这样在处理具体的业务逻辑的时候, 就不用关心数据的存储问题了.

三层架构是界面层 (UI) 业务逻辑层 (BLL) 和数据访问层 (DAL) 构成的.

MVC

MVC 是在应用程序 (BS结构) 的视图层划分出来的不同功能的几个模块.

MVC 主要是为了解决应用程序用户界面的样式替换问题, 把展示数据的 HTML 页面尽可能的和业务代码分离.

MVC 把纯净的界面展示逻辑 (用户界面) 独立到一些文件中 (Views), 把一些和用户交互的程序逻辑 (Controller) 单独放在一些文件中, 在 Views 和 Controller 中传递数据使用一些专门封装数据的实体对象, 这些对象, 统称为 Models.

MVC是模型层 (M) 界面层 (View) 和控制层 (Controller) 构成的.

区别及联系

三层架构是界面层 (UI) 业务逻辑层 (BLL) 和数据访问层 (DAL) 构成的.

MVC是模型层 (M) 界面层 (View) 和控制层 (Controller) 构成的.

而且他们之间其实并不对应, 如果硬要给他们对应的话, 那么三层架构中的UI对应MVC中的 view (jsp) , 都是用于显示以及获取界面的数据; 三层架构中的 BLL 层和 DAL 层对应 MVC 中的 Model (javabean) 层, 都是用于处理上层传递来的数据以及从数据库获取的数据的; MVC 中的 Controller (Servlet) 最多算是三层架构中的 UI 的一部分, 也就我们常说的是 Servlet.

如下图所示：

然而, 从更高层面看, 其实三层架构和MVC还是一个东西~

我们所看到的不一样只是表面上的不一样, 核心的东西是一致的, 那么什么是核心？

答曰：分层, 解耦!

如果从解耦的角度来看三层架构和MVC其实他们是一致的, 只不过划分的方法不一样罢了, 就像上面的图所示. 从这一点说他们可以说是一个东西, 这就相当于我们看到馒头和面条一样, 表面上看他们不一样 (注意仅仅是表面) 但是他们核心是一致的, 都是面做的……

小结

三层也好, MVC 也罢, 从我的感觉上, 都是对设计模式中六大设计原则的具现形式.

比如在三层中, 将数据库操作代码封装到一层中, 提供一些方法根据参数直接返回用户需要的相应数据, 这不就是单一原则的体现吗?

只要依照设计原则去开发程序, 不管什么模型, 都能开发出好的程序, 现在网上不流传一篇文章吗 <<别学框架, 学架构>>, 是的, 架构, 这种核心的东西才是值得去探讨的....

但是, 这两个架构都是更高层次的抽象, 是结构性的架构, 整个过程是"死"的, 不会去指导具体类的设计, 也不会去指导职责的划分, 这将导致逻辑控制层臃肿, 产生很多超大的“业务逻辑”类, 最终出现开篇的问题, 不方便维护, 不方便扩展.

DDD (领域驱动设计) 配合六边形架构是更好的替代架构 (领域驱动设计继承了职责驱动设计, 或者可以说是职责驱动设计的进化), 应用场景更广, 扩展更简单.