参考http://topic.csdn.net/u/20100215/16/0B7A7EC6-0E4E-4BB3-BF6D-F1ABE7C19DE0
我没想到问题这么严重，我再强调一遍：
1、面向class≠面向对象！分层不一定非要用class！物理上你可以把一个层放在多个地方，包括放在数据库里。当然，把思路打开，还有很多手段；
2、数据库就是个存储介质，逻辑上可以放任何层的内容，在逻辑上db就不是一个层，db只是物理上的层；
3、由于数据库在逻辑上的多层性，实际上可以把最终投产的数据库按逻辑功能拆分为各种单一职责的数据库，比如业务逻辑相关的应用程序数据库AppDB、应用程序无关的应用程序中心AppCenterDB（这只是举个例子）；
4、AppDB在整个开发驱动的链条上是末端的，也就是你完全可以在项目最终发布的时候才一同发布AppDB
抛砖引玉
------解决方案--------------------------------------------------------
完全不了解你要说什么
分层最终的目的就是要让不论是别人还是自己在修改维护代码时容易理解,
那么你用大家都不习惯的东西,除了让后人迷惑以外有什么好处?
------解决方案--------------------------------------------------------
楼主的功力又深了一层
------解决方案--------------------------------------------------------
看来面向类的编程和数据库驱动编程在很多人的大脑里已经根深蒂固了
----------是的，相楼主学习。你说的很好。
----我认为，我写程序时使用一种自己熟悉方式，而且这个方式经过大家实践的，又能给我的工作带来很大的方便。我就暂时接受了。程序的改进就是来方便程序员工作的。
想一想 ， 我不搞程序教学，程序系统环境开发，钻它做什么那？
------解决方案--------------------------------------------------------
数据库可以放任何层的内容?
I不明白U.
------解决方案--------------------------------------------------------
OO和数据库本来就没什么关系，
纠结于数据库设计的同时，也就抛弃了OO。
------解决方案--------------------------------------------------------
数据库就是个存储介质，逻辑上可以放任何层的内容，在逻辑上db就不是一个层，db只是物理上的层；
-----------------------
这个移植和扩展不方便，团队开发不好
也不利用自己封装dll。
------解决方案--------------------------------------------------------
呵呵，知道为啥吗？？
原因就是因为
有太多太多像lZ这样非要去条条框框去限制，非要把架构等同于数学，非要去整个公式出来的所谓的布道者太多了
就像lz上个帖子，让我去看petshop！嘿嘿，知道petshop是如何架构的人，是不会让人去看petshop滴，只有那些自以为懂了的才会去推荐petshop。
petshop是个结果，他是某种策略下的结果。结果只是结果，他体现策略，但他不是策略本身。而且petshop是作为一个教科书式的demo，他只是一个实验！就像北大青鸟的那些课堂实验一样，只是一个实验。实验的目的是演示如何在策略控制下去编程，但是他只是实验，不是现实，petshop本身过与教条，他并不美，也并不流畅，所以我才说如果理解他的策略的人，是不会去推荐的。如果不去追究策略，他只会困住你的手脚，并把你带入沟里
这就好比，我喜欢下围棋，如果有人问我如何下围棋，我说自己去看李昌镐和常昊的下的一盘棋。不，我觉不这么推荐，那是结果。如果冒然向一个不知道下棋策略的人，去推荐这样的棋，你只能把他带沟里。
ok，废话我也不多说。来看看真正的架构师是怎么说的。
如何看到一滴水的美丽
支付宝（中国）公司业务架构师
《大道至简》作者周爱民（aimingoo）
【一】
架构是一个过程，而非一个结果。
【二】
在大多数人的谈论中，架构是一个目标产物，而作为架构师的责任就是去生产它。所以无论如何，架构是可以“做”出来的，而且也应该有一些“做”的方法、技术、技巧。
有人问过我：架构的最主要产出是什么？我的答案是：图。这里面有两层含义：一层含义是如同建筑师描绘的蓝图一样，用于引导实施者；另一层含义是架构师头脑中清晰的目标系统。如果架构师头脑中没有系统清晰的图像，他是没有办法把它画出来的。
【三】
画家画的无非是物我。画物的画家，最终画的还是我见。所以，画家的笔最终描绘的是他自己心里的映像。
【四】
艺术是不可能被“生产”出来的，生产出来的，叫“艺术品”。
【五】
架构这个过程，是架构师洞见系统内在结构、规律、原则和逻辑的过程。真正的架构师是可以将自己放在系统中去的（例如作为系统中的任何一个角色），只有清晰地理解系统，才能简洁地描述它。而当架构师拿出了他所描述的“作品”的时候，架构这一过程就已经结束了。
【六】
一滴水滴落的过程中，有多少个形态的变化？‘
-----------------------------------
架构的架构
北京无限讯奇信息技术有限公司产品技术高级总监
黄冬
一位想要创业的朋友跟我说要寻找一位懂得“架构”的高人与他一起创业。要知道与代码不同的是，“虚幻”的架构常常让人认为其有很多玄妙之处，只因它大多难以落在纸上。特别是与很多大师谈及架构时，经常落入他们的一些“陷阱”，并往往为自己达不到大师的精明与技巧而叹息。殊不知，被我们所津津乐道的这些架构，是他们在日常工作里经历了大量的错误、重复的尝试、无数的代码、长久的考验所积淀下来的只言片语。
--------------------------------------------------
美丽架构之道
《构建高性能Web站点》作者
Web架构实践者
郭欣
我无法给架构下一个简单的定义，因为任何定义都会束缚你对架构的无限想象。不可否认，架构师早已出现在人类几千年前的各项生产活动中，比如建筑、音乐。而在计算机软件及Web领域，架构的设计直接影响着系统的生产，比如开发过程和效率、代码和组件复用性等，同时也影响着系统的可用性、可伸缩性、性能、容量可预测性等。
在本书中，我们更加关注架构之美。美丽的架构同样无法定义，可它却一定是自然的、简单的、可复用的、人文的，甚至是外行人也可以细细品味其思想的。当我看到超市的多个收银台排满长队时，便想到服务器并发处理性能和容量；当我看到十字路口的车辆等待转弯时，便想到它通过缓存思想来提高交通吞吐率。
那么如何设计出美丽的架构呢？从代码逻辑到物理网络，从单机到分布式，无数的技术可供架构师选择，如分层、组件化、服务化、标准化、缓存、分离、队列、复制、冗余、代理等，不过它们仍然只是“术”的范畴，而何时何处如何恰到好处地使用它们才是“道”的范畴，比如顿悟变化的道理，在博弈中寻找平衡，以系统化的角度来分析问题，寻找相对与绝对的奥秘、开放的心态……
然而，这个领域实在是太年轻了，我们需要更多的例子和经验，本书将让你大开眼界！
----------------------------------------------
看出来吗？所有优秀的架构师在关注啥？在关注过程而非结果，过程中的策略，过程中的平衡，过程中的变与不变------------方法学的意义在于体现策略，而非体现结果。知道游击战的十六字真言，你才会了解游击战
倘若你只去看结果（地道战，地雷战），你只能感叹他们咋就那么聪明呢？
------解决方案--------------------------------------------------------