前面写了这么多，很大程度上就是为了这一章做准备。面向对象或者领域驱动，最重要的一点就是要忘记数据库！我花了很长很长的时间，才理解了这一点，从而真正的迈向一个崭新的天地；而后，我又花了很长很长的时间，才勉强做到这一点；我希望，有一天，这将不再是一个问题，我不需要考虑这一点……
为什么业务层这么薄
三层架构流行起来之后，我们很清楚的知道UI层负责页面交互并调用下一层，也知道DAL层就是和数据库打交道。但BLL层？什么才算是“业务逻辑”？有各种各样的解释，但这些不都是sql做的么？对于绝大多数的应用系统而言，除了对数据库进行“增删改查”以外，实在不知道还能做些什么？更何况，不是还有超级强大的存储过程么！
所以，很多系统，即使勉强弄出一个业务层，也“薄”得不像话，像一层塑料薄膜一样，让人有一种把它立即撕掉的强烈的冲动。
为什么会是这样呢？
这得从.NET阵营从历史说起。.NET阵营的同学知道三层架构，多半是从PetShop开始，这被奉为三层架构的经典，很多项目甚至是直接复制其架构。在当时，它是一种了不起的进步。那时候，还是从ASP向ASP.NET转型的过程，很多asp项目，sql代码都还是写在html里面的！所以，UI和DAL的分离，无疑具有明细的示范效应。
但微软的步子，不大不小，刚好扯着蛋。
步子小一点，做成两层架构，估计一点问题都没有，大家都能接受；步子再大一点，就得上ORM，可惜微软当时还没条件支持。所以就搞出了这么个不明不白稀里糊涂的概念出来，折磨了我好久好久……
长期以来，.NET的阵营，在应用级层面，其实是“面向数据库”的。从DataSet、DataGrid、DataSourceBinder之类的，都可以看出来。即使是Entity Framework，最开始也是从数据库的表向.NET的类进行映射。这些，都极大的制约了.NET阵营同学面向对象的思维拓展。
好在我终于跳出来了。
面向数据库
为了说明，我们举一个最简单的例子。
需求是：记录文章（Article）的浏览数（ViewCount）。每当文章被阅读（View）一次，浏览数加一。
看到这个需求，你首先想到的是什么？是不是：
|
1
|
Update Article set ViewCount = ViewCount + 1;
|
如果是这样的话，恭喜你，你还牢牢的守住了“面向数据库”的阵地。
|
1
2
3
4
5
6
|
...阅读原文
上一篇 :
架构之路（四）：测试驱动
下一篇:
高性能服务器架构
推荐文章
1. Elasticsearch 5.x中的“冷热”架构
(R:693)[2021-11-09]
2. 数据库连接池性能比对(hikari druid c3p0 dbcp jdbc) (R:3453)[2019-05-30] 3. 可伸缩性架构常用技术之数据切分 (R:1322)[2015-06-25] 4. 不同场景下 MySQL 的迁移方案 (R:1250)[2017-01-11] 5. 数据库连接池的理解和使用 (R:1325)[2016-04-11] 6. Mysql数据库日志，备份及回滚操作 (R:1551)[2015-12-08] 7. BAT解密：互联网技术发展之路（3）- 牛逼公司的技术架构都是这个范 (R:1388)[2015-11-18] 8. 三种东西永远不要放到数据库里 (R:1241)[2015-07-20] 9. 架构之路（四）：测试驱动 (R:1264)[2015-10-25] 10. 一条慢SQL引发的改造 (R:671)[2022-03-06] 11. 亿级用户下的新浪微博平台架构 (R:1323)[2015-03-30] 12. 如何构建一个每天数十亿次请求级别的web应用？ (R:1285)[2016-01-26] 13. 数据库大型应用解决方案总结 (R:1105)[2015-07-27] 14. Mysql数据库大表添加字段方法 (R:1598)[2021-11-21] 15. 京东技术架构（二）构建需求响应式亿级商品详情页 (R:1513)[2015-09-17] |
