导航菜单
路很长,又很短
博主信息
昵   称:Cocodroid ->关于我
Q     Q:2531075716
博文数:359
阅读量:2065722
访问量:249514
至今:
×
云标签 标签球>>
云标签 - Su的技术博客
Tags : 架构,数据库发表时间: 2015-11-09 20:11:15

前面写了这么多,很大程度上就是为了这一章做准备。面向对象或者领域驱动,最重要的一点就是要忘记数据库!我花了很长很长的时间,才理解了这一点,从而真正的迈向一个崭新的天地;而后,我又花了很长很长的时间,才勉强做到这一点;我希望,有一天,这将不再是一个问题,我不需要考虑这一点……

 

为什么业务层这么薄

 

三层架构流行起来之后,我们很清楚的知道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