前面写了这么多,很大程度上就是为了这一章做准备。面向对象或者领域驱动,最重要的一点就是要忘记数据库!我花了很长很长的时间,才理解了这一点,从而真正的迈向一个崭新的天地;而后,我又花了很长很长的时间,才勉强做到这一点;我希望,有一天,这将不再是一个问题,我不需要考虑这一点……
为什么业务层这么薄
三层架构流行起来之后,我们很清楚的知道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] |