转一篇好文，虽然争议颇多，还是觉得有必要转一下看看 来自博客园
我是一名杯具的.NET程序员。学校里学的稍微过得去的只有c语言。毕业的时候总算有家公司收留做嵌入式开发，工作3个月嵌入式部门转移到外地，我一直坚定的留下来，去了公司.NET部门学习.NET.
这是一个神奇的部门，他们中大部门有很多年的java开发经验，现在他们都在.NET门下，他们一边对java语言这么多年发展缓慢发出恨铁不成钢的感叹，同时又对在C#相对强大的功能的支持下.NET居然没多大建树而倍感奇怪，他们总是用java的思想来架构.NET的程序, 跟着他们俩年我倒是没觉得有什么奇怪，因为我之前只会c语言。
后来，我辞职去了其他公司，碰到不少.NET程序员，就有点明白他们的感叹了，也是郁闷与纠结之开始。
很多.NET程序员OO思想很薄弱，以B/S模式来说，他们的三层架构是这样的，他们的项目中会有三个类库工程，而且名字都取的差不多，一个Xxx.Model, 一个Xxx.DAL, 一个Xxx.BAL. Model层就是数据库表的映射，字段与属性一一对应。 DAL层就是大段大段的拼接sql字串的逻辑，因为是拼接逻辑代码中都是用string=’ ’，而不是string.empty, 到处都是str= str1 + str1，很少用StringBuilder。BLL层就是大段大段根据业务生成字串提供给DAL层拼接成sql，不好拼接的就用视图，复杂一点用存储过程，在复杂一点，视图加数据库自定义函数之纠结，再再复杂，视图，存储过程，自定义函数与DAL层sql之纠结至死。
最后，结果就是所有的类都只有方法，没有属性，很多方法都是向下层委，很多方法都可以是static的，甚至可以全是static的，正是因为没有属性，他们的类可以轻松的用move method进行重构（^_^ ，汗,调侃），因为任何方法放在任何类里不会出错
你要是和他说你的代码不OO，就有两种典型的情况，第一种：我的代码怎么不OO了，你看这么多类，你看这么多层，我怎么不OO了，我用的纯OO的C#哦，怎么不OO. 第二种：OO也不能解决所有问题，这三层架构是经典架构啊，是OO的改进，微软推荐的做法。对于第一种，我基本保持距离，那是OO门外汉，搞不好还是编程门外汉。对于第二种，用C#这种纯OO语言，基于.net framework这样纯OO架构的框架做开发，不用面向对象的思想来设计程序架构你打算什么时候用啊？用C++的人不利用面向对象的思想来设计他的代码，还用C++干什么，用C多直接。究其原因是.NET程序员不知道三层架构某种程度上和OO是有冲突地，属性和操作分离违背了类的基本定义。虽然三层架构对java来说也是一样有矛盾的，但人java至少还知道这个问题啊，所以有贫血模型，充血模型，领域模型，ORM之类的试图解决这样的冲突。还有中观点更少数更让人纠结，说程序员只要是利用OO研究的成果，按这样的意思，用纯对象语言编写过程式的程序，利用面向对象的.net framework也行啊？这不有病吗？
.NET程序员大部门不知道依赖注入，不知道面向方面（切面）编程，所以给他们介绍Spring.net, ObjectBuilder,他们就难以接受，拒绝的理由就让我郁闷，有用框架啊，有多写好多类，这么多配置啊，对性能有影响吧。所以他们的代码中，”函数三段论”在每个函数都有，这三段就是：执行逻辑，写日志， 处理异常，重复的三段论看着很纠结。 最后，就算是微软企业库中的DataAccess Block他们也很难接受，因为他们钟爱的是SQLHelper。
每次有项目来，在我还在规划有什么类，有什么属性和操作的时候，很多.NET程序员数据库中表都已经建好了。我并不反对先建数据库，不过数据库与对象如何衔接就得要先考虑了。但是他们并不了解关系模型与对象模型之间的区别。所以再建好了数据库之后，就
开始建个模型。建完了总得要操作数据库吧，所以再建个DAL，但是现在什么业务逻辑都没有，所以DAL层就开始组合下sql语句的拼接逻辑，然后上层就可以提供字串给DAL拼凑了，上层是什么，BLL啊，最终，把整个程序扫一遍你就发现，编程就是sql字串到处流动并在流动中由短变长，由简单变复杂。要不就是sql写在存储过程中，程序是存储过程执行的条件到处流动。如此郁闷之纠结，你一眼看上去还以为是个字串或者文本处理程序。
总结，都已经到了后OO时代了，.很多net程序员依然还以青铜时代的观念和方式使用热兵器
=================================我是分割线======================================
来源博客园 ：http://www.cnblogs.com/wangchangming/archive/2010/09/30/1839620.html
[解决办法]
昨天刚看过，说的还是有点道理的
[解决办法]
额。 路过。 。
[解决办法]
如果不拼接SQL？那有什么好方法吗？
LINQ？？
[解决办法]
抢楼!!
[解决办法]
不能认同，悲剧路过
[解决办法]
sql语句执行速度快呀！
[解决办法]
还在sql拼接??
在.net下看看强类型的DataSet!!
[解决办法]
[解决办法]
[解决办法]
所谓强类型的DataSet,是vs2005后才真正开始!
用强类型的DataSet来开发本来就不多,
何来"强类型的DataSet现在都很少用了"???
[解决办法]
[解决办法]
[解决办法]
[解决办法]
[解决办法]
抢分 顶！
[解决办法]
值得思考，反思
[解决办法]
值得好好思考一下的啊！
[解决办法]
如果只是为了访问一下关系数据库，甚至都只是本地访问（而不是跨互联网访问），那么大可不必先把旗帜举的太高。面向对象不是只是针对访问数据库时的操作的，而是针对整个大系统的设计和持续改进。如果全局架构是面向对象的，反而在访问数据库方面似乎不必太急于纠结过度建模。
lz的前半段空谈时是很有启发的，可惜后边一旦举了具体的实例，就带有一些缺乏阶段实用性而过度追求僵化模式之嫌了。
[解决办法]
如果我们自己开发ORM，一腔热血之时肯定会写出这类文字。不过如果看现实，以工程的方式来组织好复杂的项目，更重要。
我的看法是要打破常规，但是又不能过度。你的团队中有人直接拼sql，有人使用自己写的ORM框架，有人使用Linq to SQL之类的，甚至有人直接以二进制文件方式去打开所有数据库文件然后改写，都可以！作为组织者，是要尽可能包容不同方式，唯一能够做出评判（并且用来协调技术和管理进度）的就只是自动测试。不管你用什么方法，我每隔几个小时运行几千几万个测试，通过了就是好的，出现bug了就请别的什么都不要干专心解决bug吧！只要保持一种务实、可行的敏捷开发状态，这样每个人自己就会评判出别人的做法是否比自己的做法更好、更值钱！而过分早地挑起理论之争往往只会得到一堆垃圾结论，过一段时间就忘记了。
[解决办法]
[解决办法]
[解决办法]
up.
[解决办法]
赞同p哥,"不管用什么方法要只要测试通过"
就我的工作而言是,"不管用什么方法,以最快的速度交付用户",(当然要测试通过)
[解决办法]
我随便举一个例子吧。假设系统需要有一个功能，它可以自动查到系统有哪些扩展程序，然后就自动在一个看板上列出所有扩展功能供用户选择。它不但可以自动处理界面的显示，而且可以处理用户的操作（例如拖放一个功能到用户自己的任务栏里来安排自动启动任务，或者改变设置一个功能的默认属性等等）。作为一个项目组织者，你只需要写出这个功能的详细设计要求，然后实现它，并发布那些可以被这个功能所示别的其它功能的必要的接口（例如功能如何展示大图标、小图标、标题、用于定时启动的属性，当启动时如何由宿主系统给它传递用户单点登录信息，等等），然后其它程序员就去使用它来挂上各自的功能，各自的扩展程序神奇地被系统所发现、所导航。作为项目组织者，你需要的是详细设计出这种核心类的组件，并且找一个最得力的程序员来实现它，然后教给其它人如何使用它，而组织者则只是在平日里去随时启动针对这个功能的测试用例来扫描一下看看项目组里所有的具有此接口的功能实现时是否有bug。
我们用不着教什么理论，使用它的程序员自然学会了面向对象编程。因为它们实现了这个接口，从这个接口的操作流程中受益，甚至继承了自己的实现而扩展了功能。
但是如果我只是从csdn上抄来一段空话，然后就把一个“设计任务”分配给了程序员，这就是过高的要求。能做架构师职责的程序员工资是多少？
因此其实最大的问题，可能是做.net的小公司大多只能找到一些较早来公司的程序员来做项目经理甚至做架构师来让产品更适应市场需求变化，而做java的小公司则以为养两个动不动就建模、动不动就写书的程序员可以控制项目进度。其实如果程序员因为加班辛苦而死，.net程序员可能是笨死累死的，而java程序员可能是说空话郁闷而死。项目的组织者自己会提高设计和控制的水平，但是不到必要的时候没有必要教会程序员这些，因为他们往往还没有学会三分像就想着自己应该打出山门出去闯闯了。
[解决办法]
把三层架构理解为三个类库工程确实不是好的想法。类库工程应该按模块划分，单个模块的三层一般可以放在同一类库中，这样比较合理。
很难想象会有很多没有属性的非静态类(系统类库扩展除外)，确实不正常，你真的见到过吗？
也有一些不是很认同
1.简单的SQL逻辑用可以程序生成实体类解决，而对于复杂的逻辑不拼SQL，请问有什么方法生成高效的查询？
2.OO是为代码重用而生，不要为了OO而OO，比如全局静态的单例一般都没什么意义，也是很容易出现的。有某些时候确实想用C，可是能在C#中简单的用吗？
3.很少用StringBuilder应该是正常情况，只有在一定量的字符串拼接的时候StringBuilder才有意义。
4.我从来都没觉得三层架构与OO有不可解决的冲突，实体类都是程序生成的。
5.面向切面编程，不了解。查了一下百度百科，第一感觉是不仅执行效率低，而且代码量大，复杂度高。而且从本质上没有解决问题，不过是转移了位置。"重复的三段"反而逻辑更清楚，控制力度更强。
6."在我还在规划有什么类，有什么属性和操作的时候，很多.NET程序员数据库中表都已经建好了"，也许某些时候是自己慢了半拍(开的玩笑)，难道别人没有可以已经规划好了？