今天看了很多所谓n层、3层、mvc误导，什么高手不用存储过程。看了就晕。作为一个为资深程序员（年纪大，到现在都还是程序员），我要以正视听，当然只是我一家之言。
首先搞明白什么是3层，否则说啥都是白说。在90年代3层结构指的就是：表现层、中间层、数据层。
表现层就是界面，中间层就是逻辑。数据层就是保存数据的地方。对啊，就是数据库，不要把什么数据访问层拖入来，那是错的。
三层架构最流行的时候应该是90年代后期，delphi横行的时期，企业开发基本围绕着client、com+、database。李维写了本关于com+的名著（什么是名著，就是那个人不出名，书先出名了），明确地提出中间层就是com+，如果有机会你可以问问李老大. 那个数据访问层在哪里？
接着要说N层，2002年末，M$发布了vs2003与EJB竞争，之前有个很废的vs2001。大家可能已经不记得vs2003发布的口号是“一切皆是.net”, 靠！那是啥？当时我也云里的雾里的，后来几年后，看了某外国名人的blog，说是以WebService为中心的分布式体系，由于过高估计webService的应用或者应该是过高估计分布式运算，最后被外界评为失败的产品。哦 离题了。
注意力回来一下，集中在当时随着vs2003发布的企业级例子——duwamish7.0。卢彦的Duwamish深入剖析-结构篇 ，里面非常明确地提出N-层架构，这个不敢乱吹，直接引用原话：
“ 比较令人困惑的是其中的业务外观层和业务规则层，很多人在学习N层结构开发的时候，听得最多的是三层结构，分别为：表示层，中间层和数据层。 Duwamish的WEB层和数据访问层比较好理解，也就是传统意义上的表示层和数据层，那么业务外观层和业务规则层和我们熟悉的中间层有什么联系呢？”
Duwamish发布后，最多人讨论的是现在被人误会为三层架构的外观层、逻辑层、数据访问层（随着时间的迁移，变成了3层，晕，可能是自己笨，没有跟上潮流），还有就是用于传递数据的entity——DataSet。当时的最佳实践是强类型DataSet。如果不是有java的Hibernate 和EJB做对比，其实它也真的不错。
当时的Duwamish是.net体系下可伸缩应用的最佳实践。怎样伸缩可以参考这里（10分钟内，我找不到更好的了）。我依葫芦画葫芦，也画了不少这样的项目，但是分布应用，就真的谈不上，因为不是每个项目都需要分布。但是这个例子改变了不少90年代过渡的M$的程序员。也就奠定了.net开发的基本模式。但是以当时.net的示例（包括后来的PetShop C#），他的开发模式上还是追不上EJB，但是EJB复杂度追上了com+，所以出了个hibernate。Java在2002年的时候（大概了，我也不记得啦），老马大叔就为hibernate发明了个充血模式和贫血模式。到现在你还可以从javaeye上面找到当年（就上一年还在吵ruby和java的充血模式）的吵架贴。
无论我赶不赶上潮流，分层都是必须的。最容易理解的开发模式是把中间层被划分为3个层，也就是大家说的外观（绝对不是UI）、逻辑、数据访问。而在这个几个层之间是往来的是entity。这个entity可以使duwamish的强类型dataset，可以是只有get和set的贫血对象。
无论分多少层，应该怎样划分，目标非常明确是为了解耦，为了关注点分离，为了可伸缩。那位到处叫人看自己blog的小伙，我觉得你是胡说八道。现在例举以下八道：
国外不谈分层，并不是云计算。我看不出他们有什么必然的联系。那是胡说1道
"那是microsoft阴谋"那是胡说2道。.net可以不分层。用三层写程序，完全可以用java实现。看不出microsoft的阴谋是啥？
“三层是关于部署（Deployment）和（Security)的，和开发关系不大。“ 这个我想写胡说4道的，某个角度是对的，不过还是严重建议你去看飞林沙 的关于物理部署的内容。这个暂且算0.5道
“三层违反DRY原则" ！？那个部分违反了？我外语差，也知道youself是什么，n层中那个地方违反了？ “效率会更好”，new 3个instance，一个接着调用一个，会比一个instance，调用一次完成快？我不敢说会慢很多，但至少不会快吧。所以那是胡说4.5道。
"微软的那个架构里面，全部使用存储过程"？ 又那个msdn上面推荐你全面使用存储过程。又那个老大告诉你，用了存储过程就不能写三层啊。胡说5.5道。
"M$的MVC 有误导".你不要误导我，举例说明，不要空口说梦话。那是胡说6.5道。我认mvc不够完美，但是不能说有误导，误导了什么？概念？开发效率？平台？
高手不用存储过程，靠，那么用存储过程的一定不是高手。胡说7.5道。
最后，不要一来到终极领悟，乱发首页加上误认子弟，这0.5，我送的。
夜了，就当我胡说八道好啦。