你用.NET开发OO了吗？

美图秀秀2017v5.0.0.5 官方正式版

• 类型：图像处理大小：34.4M语言：中文 评分：8.1
• 标签：

立即下载

我是一名杯具的.NET程序员。学校里学的稍微过得去的只有c语言。毕业的时候总算有家公司收留做嵌入式开发，工作3个月嵌入式部门转移到外地，我一直坚定的留下来，去了公司.NET部门学习.NET.

衡量一个程序员的水平不是看他懂多少东西,会不会OO或者别的,而是要看他的代码是否易懂,是否高效,是否能灵活扩展.能做到这些管他什么OO,AOP,SOA,MVC,N层架构之类的.记住,能够以更好的方法解决切实的问题才是王道.

这是一个神奇的部门，他们中大部门有很多年的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程序员依然还以青铜时代的观念和方式使用热兵器