我是一名杯具的.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程序员依然还以青铜时代的观念和方式使用热兵器
转一篇好文,虽然争议颇多,还是觉得有必要转一下看看 来自博客园
最新推荐文章于 2024-08-26 11:27:47 发布