面向数据库
　　为了说明，我们举一个简单的例子。
　　需求是：记录文章（Article）的浏览数（ViewCount）。每当文章被阅读（View）一次，浏览数加一。
　　看到这个需求，你首先想到的是什么？是不是：
　　Update Article set ViewCount = ViewCount + 1;
　　如果是这样的话，恭喜你，你还牢牢的守住了“面向数据库”的阵地。
　　/*
　　面向数据库并不是不可接受的，面向对象也并不一定比面向数据库“高级”。
　　这只是两条道路的选择，如果你愿意看一看另外一条路的风景，请继续；否则，此打住吧。
　　*/
　　面向对象
　　public void View()
　　{
　　//从数据库中取出Article
　　Article article = session.Load<Article>(articleId);
　　//改变Article的ViewCount属性
　　article.ViewCount += 1;
　　//将改变后的Article再存入数据库
　　session.Save(article);
　　}
　　有什么感觉？眼前一亮，还是不可思议？想得更深一点的，是不是觉得这是多此一举，一句sql能解决的问题，搞得这么复杂？
　　我当年，考虑多的，不能接受的，是 性能问题。
　　这必须利用ORM，即使不考虑ORM生成的sql高不高效，这生成sql的开销，应该不低吧？
　　这样做，取数据，打开一次数据库连接；存数据，又打开一次数据库连接。算有连接池，但能省一点省一点不是更好？
　　所以，如果你也和我一样，倒回去看我之前的博客吧！
　　这样做，还有其他很多具体的技术问题，我们后续博客会逐一展开说明。
　　为什么
　　我们还是回到大方向上来，为什么要这么做？换言之，“面向数据库”有什么问题，或者说“面向对象”有什么好处？
　　我觉得，“抽象”、“解耦”、“复用”之类的说法，都还没有触及根本。根本的原因，还在于我们的大脑，我们的大脑不适应于把这个世界抽象成一张一张的表，而更适应于一个一个的对象。随着系统日趋复杂，这种现象表现得越明显。
　　我曾经参与过一个项目，它的数据库结构打印出来，得用地图那么大一张纸（我不知道算A几了），密密麻麻的全是表，各种线条交错其中，我看着头皮发麻。部门里面像个宝贝一样把这张表供着，因为公司没法打印也没法复印啊！（我不知道他们开始是怎么得来的，估计肯定麻烦）
　　如果你一边读一边在想，会发现，“不对呀，有多少表有多少类，类图不是一样复杂吗？”
　　是的，而且由于抽象，类很可能比表还要多。但是，有于抽象，在我们进行架构、设计、沟通的时候，可以暂时的抛弃很多细节。比如，我们可以说，“文章 被评论之后，文章作者的积分加10分”，这个时候，我们不考虑文章有很多种：博客、新闻、问答、评论……，也不考虑积分增加是直接改积分总分呢，还是添 加一条积分记录，或者还要同步……。如果只有表，你怎么说？
　　当然，表的结构也可以设计成类似于继承的样子（类的继承关系也终会映射成表结构），但是，在交流沟通中，你如何表明这种抽象关系呢？
　　单纯从程序的角度上说，使用ORM，面向对象，还增加了系统的复杂性。毕竟多了一道工作，而且把对象映射到数据库不是一件简单的工作，尤其是你还要考虑性能问题的时候。
　　那为什么我们还要这样做？委托，换言之，把复杂性往其他地方推。我记得我反复讲过这一点，架构的一个重要工作，是把复杂性进行拆分和推诿。拆分估计大家好理解，但“推诿”是个什么意思，推给谁呢？管它呢，我只做我分类的事，其他的，UI推给BLL，BLL推给DAL，DAL推给DBA，DBA推给采购部……
　　写在这里很搞笑，但事实是这样的。在 性能篇，我说，你要写高性能的代码，你是抢了人家的饭碗，这个意思。UI都把DBA的活儿干了，人家吃什么？你代码都写成01001010101010二进制了，别说做汇编的，估计做CPU的都活不下去了。
　　我们这里，是把复杂度推给了Map团队、ORM工具开发商和DBA。
　　因为我们要和客户谈需求啊，典型的是领域驱动，要和客户/领域专家找到“共同的语言”，这共同的语言是什么？是表结构？估计如果开发的是一个财务会 计系统，这还是可行的——估计早期的系统大多是财务报表类系统？说不定还真是这样。为什么面向对象从Java开始流行，Java是虚拟机，可以用在微波 炉报警器之类上面的，底层数据结构可以完全脱离数据库啊！.NET做什么起家的，报表啊！呵呵。
　　总之，发展到，随着系统复杂性的增加。在系统的架构设计中，我们不得不将现实世界首先映射成一个一个可以封装、具有继承多态特性的对象，并且将重心放在这些对象关系功能的维护上。
　　数据库？先不管它吧。
　　只有脱离了数据库的束缚，我们才能自由的翱翔在面向对象的世界里！
　　忘不掉
　　“问题是我忘不掉啊！”
　　“我只要看到需求，脑子里马上是数据库是表。”
　　“没有数据库，我都不知道怎么开始写代码了。”
　　……
　　是的，忘掉数据库是很难很难——尤其是对于我们这些老人来说。已经浸淫sql数十年的高手，你让我忘掉它？你以为写小说啊，张无忌学太极啊？
　　我只能说说我是怎么做到的，希望能给你一些参考。
　　我假设我的系统不是用“关系数据库”存储数据，不是mysql，不是oracle；我用nosql，我用xml文件存储，行不行？nosql，怎 么用？不知道啊，我十窍通了九窍。但我要在我还不知道nosql怎么用的时候，开始构建我的BLL/领域层。而且我只设定几个简单的假设：
　　所有的对象都可以直接从硬盘Load()出来
　　所有的对象都可以直接Save()到硬盘
　　对象之间用1:1、1:n、n:n建立关联即可
　　究竟怎么从硬盘里存取（所谓的“持久化”），以后再说。我连用什么进行持久化都不知道，现在怎么考虑？但有一条，反正不会用关系数据库，估计是用NoSQL吧……
　　终的期望
　　真正的对象数据库！快出来啊，求你了……
　　惯例说我的项目进展：
　　1、写文档写到吐……
　　2、重构累成了狗……
　　本计划发布了新版本再写这篇博客的，但实在不能再拖了。博客系列接下来，进入项目的具体开发了，代码还乱成一堆，啊……