对于只有几个表的数据库和页面的小玩具我不认为有建模的必要性，但在大型系统中对象建模和面向数据库建模是非常重要的。
对于一个有100多个表的数据库甚至数次建模也无法100%保证它能正常的实现所需功能，因为在系统完成前你无法测试它的准
确性。当你完成一个系统，却发现现有的数据库无法实现查询某些数据怎么办？推翻重来？这就是为什么世界上有70%以上IT
项目失败的原因。
软件工程之所以叫做工程，特别是基于商务的web system, 它的复杂在于业务逻辑，软硬件的安全策略，性能和可维护性。
一项软件工程的成功实施，并不在于开发者是否聪慧过人或者有几个软件英雄;而是在于三个重要角色，架构师，技术总监和DBA。
DBA重要性 == 架构师 > 技术总监
合格的架构师最主要的一项指标就是基本什么都精通。他规划出系统构架，主要就是建模和OOD，程序员可以很轻松的在代码层
上完成工作，并且无法超越架构之外。整个项目都沿架构呈良性开发。注意，沿架构开发并不是架构师说给你的，而是你的代码
只能沿架构走，否则无法写下去。比如你一直用button click + response.redirect("adfd.aspx")联接到另一个页
面;但在架构师的架构下，你只需用MyPageControl.Add(ANewPage)就实现了同样功能。又比如你用Session["Abc"]=
ABC来保存对象，页面多了，连自己都忘了哪个session是哪个了，因此架构师的架构不用你自己控制session，帮你封装好。
又如系统里有用户业务，交易业务，帐目业务等几十种业务逻辑，它们都需要实现分布式transaction，是不是每个逻辑都需
重复的transaction代码，还是OOD继承更有效率，还是SOA更容易维护？架构师来决定。程序员只需添加业务逻辑而不必关心
如何实现这种分布式处理，因此即使这种分布式处理方式改变，也不需修改任何业务逻辑代码，效率自然提高。这就是建模的重
要性之一。而且没有8-10年以上的开发经验，所谓的架构师只是吹出来的。
技术总监和DBA就不想说太多的。以前公司里一个高手，我问，如何将aspx页面表格生成EXCEL，WORD，PDF文件？过了一天，
他搞了一个FileGeneratorControl，可以直接放到页面里用了; 分页？他搞了一个PagerControl，放到页面里直接用了;
页面相册？他搞了一个PhotoViewControl，放到页面里直接用了, 还是AJAX的。
并不是为了‘面向对象’而面向对象，但感觉许多所谓高手是用无穷尽华丽的词藻，晦涩的概念来显示自己的‘高深技术’，其实
真正水平并不怎样。说软件行业是青春饭也是不正常的一种态度。如果喜欢技术，钻研下去，待学的东西是无穷尽的，前途也很
光明。没有对技术的透彻理解和系统架构的认识，只能永远停留为程序员。想做真正的技术总监还是架构师？
