转一篇好文，虽然争议颇多，还是觉得有必要转一下看看 来自博客园

我是一名杯具的.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

解决方案 »

  1.   

    我怎么感觉 就是那么回事呢
    很郁闷 写的代码 操作数据库 全部都是 sql拼接啥的
      

  2.   

    如果不拼接SQL？那有什么好方法吗？
    LINQ？？
      

  3.   

    还在sql拼接??
    在.net下看看强类型的DataSet!!
      

  4.   

    强类型的DataSet现在都很少用了
    都用Ilist了
      

  5.   

    所谓强类型的DataSet,是vs2005后才真正开始!
    用强类型的DataSet来开发本来就不多,
    何来"强类型的DataSet现在都很少用了"???
      

  6.   

    我都不知道什么是强类型的DataSet，基本上都是使用实体类
    刚刚查了一下“强类型的DataSet”，好像是直接从IDE界面设置或者拖拉控件设置吧
      

  7.   

    不是的 就是一个数据类型
    DataSet
      

  8.   

    如果我们自己开发ORM，一腔热血之时肯定会写出这类文字。不过如果看现实，以工程的方式来组织好复杂的项目，更重要。我的看法是要打破常规，但是又不能过度。你的团队中有人直接拼sql，有人使用自己写的ORM框架，有人使用Linq to SQL之类的，甚至有人直接以二进制文件方式去打开所有数据库文件然后改写，都可以！作为组织者，是要尽可能包容不同方式，唯一能够做出评判（并且用来协调技术和管理进度）的就只是自动测试。不管你用什么方法，我每隔几个小时运行几千几万个测试，通过了就是好的，出现bug了就请别的什么都不要干专心解决bug吧！只要保持一种务实、可行的敏捷开发状态，这样每个人自己就会评判出别人的做法是否比自己的做法更好、更值钱！而过分早地挑起理论之争往往只会得到一堆垃圾结论，过一段时间就忘记了。
      

  9.   

    我随便举一个例子吧。假设系统需要有一个功能，它可以自动查到系统有哪些扩展程序，然后就自动在一个看板上列出所有扩展功能供用户选择。它不但可以自动处理界面的显示，而且可以处理用户的操作（例如拖放一个功能到用户自己的任务栏里来安排自动启动任务，或者改变设置一个功能的默认属性等等）。作为一个项目组织者，你只需要写出这个功能的详细设计要求，然后实现它，并发布那些可以被这个功能所示别的其它功能的必要的接口（例如功能如何展示大图标、小图标、标题、用于定时启动的属性，当启动时如何由宿主系统给它传递用户单点登录信息，等等），然后其它程序员就去使用它来挂上各自的功能，各自的扩展程序神奇地被系统所发现、所导航。作为项目组织者，你需要的是详细设计出这种核心类的组件，并且找一个最得力的程序员来实现它，然后教给其它人如何使用它，而组织者则只是在平日里去随时启动针对这个功能的测试用例来扫描一下看看项目组里所有的具有此接口的功能实现时是否有bug。我们用不着教什么理论，使用它的程序员自然学会了面向对象编程。因为它们实现了这个接口，从这个接口的操作流程中受益，甚至继承了自己的实现而扩展了功能。但是如果我只是从csdn上抄来一段空话，然后就把一个“设计任务”分配给了程序员，这就是过高的要求。能做架构师职责的程序员工资是多少？因此其实最大的问题，可能是做.net的小公司大多只能找到一些较早来公司的程序员来做项目经理甚至做架构师来让产品更适应市场需求变化，而做java的小公司则以为养两个动不动就建模、动不动就写书的程序员可以控制项目进度。其实如果程序员因为加班辛苦而死，.net程序员可能是笨死累死的，而java程序员可能是说空话郁闷而死。项目的组织者自己会提高设计和控制的水平，但是不到必要的时候没有必要教会程序员这些，因为他们往往还没有学会三分像就想着自己应该打出山门出去闯闯了。
      

  10.   

    把三层架构理解为三个类库工程确实不是好的想法。类库工程应该按模块划分，单个模块的三层一般可以放在同一类库中，这样比较合理。
    很难想象会有很多没有属性的非静态类(系统类库扩展除外)，确实不正常，你真的见到过吗？也有一些不是很认同
    1.简单的SQL逻辑用可以程序生成实体类解决，而对于复杂的逻辑不拼SQL，请问有什么方法生成高效的查询？
    2.OO是为代码重用而生，不要为了OO而OO，比如全局静态的单例一般都没什么意义，也是很容易出现的。有某些时候确实想用C，可是能在C#中简单的用吗？
    3.很少用StringBuilder应该是正常情况，只有在一定量的字符串拼接的时候StringBuilder才有意义。
    4.我从来都没觉得三层架构与OO有不可解决的冲突，实体类都是程序生成的。
    5.面向切面编程，不了解。查了一下百度百科，第一感觉是不仅执行效率低，而且代码量大，复杂度高。而且从本质上没有解决问题，不过是转移了位置。"重复的三段"反而逻辑更清楚，控制力度更强。
    6."在我还在规划有什么类，有什么属性和操作的时候，很多.NET程序员数据库中表都已经建好了"，也许某些时候是自己慢了半拍(开的玩笑)，难道别人没有可以已经规划好了？
      

  11.   

    这只能说明.NET开发人员水平参差不齐，其实Java开发人员也一样
      

  12.   

    看了这篇，的确有些感触总体上我觉得，是环境和思想的冲突这些年托X鸟那种培训机构的福，俺们这行总体上充满一种“积极向上”的氛围。问题是OO这种东西，不是弄几个“新技术，新工具”这种短平快的学习方式可以解决的。OO说穿了还是一种世界观的问题，需要很长时间的积累才能看到效果。我经常开玩笑说：“OO程序员基本可以算半个哲学家，不过是代码员常有，而哲学家不常有”ok，既然哲学家不常有，那么coder们该如何自处？于是大部分人开始搞“货物崇拜”，坚持两个凡是
    “1。凡是微软滴都是优秀地，包括petshop，wcf，wpf---”
    “2。凡是老外大牛们说的都是好滴，包括设计模式，敏捷”问题是在你没明白petshop为啥那么做的时候，你只能照搬，但搬还没搬对。petshop只是结果，而架构整个petshop的过程你没看到，你只看到那个结果了。在来看看老外们，如此强调重构，强调测试，强调敏捷，强调OO，强调函数式--------实际上从这几个强调，你可以看到实际老外强调的不是结果和形式，而是强调过程和思维方式-----这才是我们国内和他们最大的差距
      

  13.   


    除了LINQ 
    NHibernate也可尝试 
      

  14.   

    看过了。oo这东西该用的东西肯定要用，不该用的东西干嘛要用。
    select 一下。不必弄的一定要oo吧。现在正在弄一个东西。75%以上用了oo。不用的话。处理起来确实有些复杂。
      

  15.   

    有些小诡异
    .net优秀的程序员还是很多的
    当然,还有更多的不合格的程序员(我估计算是其中一名)
    同样的,java里面有很多优秀的程序员,也有很多不怎么样的综观全文,我觉得那个作者是在拿优秀的java程序员与不合格的.net程序员做比较这个意义其实不大,只不过有太多人神经太紧张了,一旦同一篇文章里面出现java与.net两个词汇,他们就双目圆瞪,随时准备打一场捍卫语言(平台)荣誉的圣战其实有那个时间,就算你不去学习编程,去看看电影,溜溜小狗也是好的
      

  16.   

    LINQ to entity 很推崇？我觉得性能上的损失很严重啊。
      

  17.   

    我是小菜，现在正在学.Net，从ASP转过来的
      

  18.   


    这个我看就算了吧！
    Nhibernate一大堆的配置文件又能体现出什么？
    java的东西有时候拿到.net上面来不一定适合！
      

  19.   

    我看过一个项目里，所有的数据库操作写在一个dao里面，1000多行啊，当场晕倒。我是做java的，数据库拼接的确麻烦，ibatis是个很好的解决方案，现在也有.net版本了，谁用谁知道，一用忘不掉。
      

  20.   

    面向对象就是ooa,ood,oop,因此，既然我们用了面向对象的开发语言，就应该尽可能多的使用这种思维方式，但是关系数据库是一种关系模式，不是面向对象的模式，所以在javaweb中有个持久层，该层如使用hibernate 框架，就可以很好的解决对象类型和关系类型的转换，如何产生表，这些都是有hibernate处理，而我们要更多关注的则是对象类型，这岂不是做到了更加面向对象了吗
      

  21.   

    三层就跟oo冲突了？这也太形而上学了充血 贫血 还是aop 又或者是spring.net这些并不重要，重要的是解耦 抽象的过程
      

  22.   

    d  d  d