模拟项目小结

 

     很久没写什么东西，也很久没上来看看帖子了。模拟项目磕磕绊绊总算做完了，很久没看帖觉得整个人都变得龌龊了很多，连照镜子的想法都没有了，也没有了面向对象的感觉，真是的，跳进代码里面就不知道东南西北了:-)

     （PS：我从来没隔这么久没梳过头，到上海快三个月了吧，还没梳过头，^_^）

     模拟项目做完之后，总有些意犹未尽。这倒不是说，还想继续做点什么，而是觉得项目中还有很多东西其实是可以做得更好一点的。而我们又没有做，不是没有具体发现这些工程上的缺点，而是要鼓起勇气去改，还是很难的，提出这个意思也是要受到很多人的反对的，因为重构或者说是改进，往往不是一个人的事情，是一个整体的事，动一发而牵动全身。
这让我更觉得需求和high-level-design（或许说是DDD更准确）的利害了。
我们常常说做软件要有拥抱变化的勇气，但是对于很多人来说大部分变化都不是源于需求的变更，而是源于需求的不完善和设计的不成熟。
     今天看了Jdon 的“数据库岂能不亡”之后，终于大概了解了，为什么banq说数据库已死（ 之前居然看了两遍的banq的“数据库已死”都没有看懂，难道是做了项目之后脑袋变聪明了）。我之前对一个项目中数据库的位置看来也很有问题。总是以为数据库才是最重要的，存储过程，复杂的sql语句才是性能的提高的关键，但是这样的话，在巨大的访问量，整个软件的瓶颈很显然就是数据库这块了。
      当我们放弃以数据库为中心的设计，DDD把业务逻辑往上层提一下，也就是说把放弃使用存储过程和复杂的sql语句，这部分逻辑转由上层的service完成，dao提供更为原始的数据。在使用更多是聚合型数据，虽然在第一次取数据时看起来对数据库是一个很大的压力和无必要，但是这样就用到了hibernate的缓冲，使用复杂的sql语句很显然是反缓冲的，使得数据的命中率极为低下，这样还不如直接使用jdbc好了。假如因为访问量巨大而造成的系统运行缓慢，俨然使用DDD这样的设计出的软件在增加了硬件之后会有一定的性能提升，虽然也不是线性的。但是如果使用面向数据库的编程，靠的是sql语句的查询得到具体到点上的数据（看似数据量很少，很精确，似乎效率很高）和存储过程来保证数据的正确一致，所有的工作都是数据库在做，怎样做才能使得数据库的效率得到提高。反过来看，当使用面向数据库的设计时，看看写出来的代码，重用性？？还有在变换了数据库之后怎么办？？很多使用面向对象的框架也能写出一手面向对象的程序，当看到这些程序时，会发现最后的dao才是真正的重头戏，其他层都是在传递参数，这样使用框架是不是有点暴殄天物,。。。