学会放弃

my blog is here

  博客园 :: 首页 :: 博问 :: 闪存 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::

最近有幸参与了一个生管软件的SAAS开发,也做了两周的编程。总体感觉有可取之处,但更多的是感觉运行速度慢,开发效率低。下面就简单分析一下。

软件采用.net 3.5,开发工具用VS2008,数据库sql 2005。系统也进行了分层,有ASP.NET表现层,业务管理层,数据访问层,数据库本身也算一层吧。

 

在表现层和业务层之间用了Microsoft.Practices.Unity工具,用于在表现层调用业务管理层时,能实现一个接口转换。在表现层,编程时使用业务管理层的对象所对应的接口,程序运行时,Unity工具会实现真正业务对象的调用。表现层和业务层之间传递数据的是所谓的“域模型”,一般命名成xxxInfo类,但我感觉更象个“实体类”。

 

数据访问层是通过ADO.NET Entity Framework,微软最新推出的一个所谓ORM的工具,当然,在VS中拖入表结构,再设置一些实体模型,数据模型的对应关系,就能全部生成数据的访问,代码几乎不用写。

 

业务层,业务管理对象,一般命名成ManageXXX主要实现查询,新增,修改,删除(CRUD)的包装,如新增或修改操作时,先调用数据库成的EF创建一个EF的实体模型对象,如果是新增就创建一个新的,如果是修改就根据ID捞一个,再将UI层包装过的Info对象,字段一一映射到实体模型对象,调用EFSaveChanges方法。当然取数据时,是从EF实体模型一一映射到Info对象。

 

总体的架构就是这样。我以个人感觉来说说这样做有什么不好。

 

数据库EF是微软刚推出的技术,看了MSDN,感觉是不错,但真正用起来,我感觉没多少人用得好,大家还是对传统的ADO技术比较熟悉,一些特别的功能实现上,在业务管理类中,用了一些EA LINQ的语法,EA 实体语法,EASQL用得不多,访问EA就这三种技术,因为技术上不熟悉,会导致有时候感觉效率狂底,反正我开发起来,第1次操作一条记录都是非常慢的。比如更新一个订单,假设订单主表关联的其它表比较多,如客户,业务员,付款方式,币种,汇率,运送方式等等之类的,或取这个对象时,如果没有“延迟加载”,不知要加载多少个对象,还有万一对象设计的不好,造成循环加载就麻烦了。用了新技术,使得新进人员跟上的速度慢了,真担心以后的效率问题。

 

另一点,最主要做得差的地方,就是所谓的域模型xxxInfo类。我们心目中面向对象技术真正的域模型,是一种对象包含相关的对象,而现在的域模型,里面就是对数据库字段的简单set,get,偶而加一些界面上用到的对象信息,所以,我说这是一个实体类还差不多,最令人不解的是,这些Info类里的字段,是原始的字段,而EF调的时候却是对象。比如,Order表里有CustID字段,EF里是Order.Customer,而Info类却是CustID。这样,取数据时,要传换成Order.Customer.CustID。写数据时,要new Customer(CustID),就是这个意思了,感觉不是在做无用功吗,取数据时,Info类只要CustID,现在我估计EF又从Customer表根据ID得到一个Customer数据对象。 写数据时,Info类里只有CustID,为了满足EF的存储需要,又要根据CustID得到一个Customer数据对象,再赋给Order数据对象的Customer对象,因为他们存在关联啊。感觉就是在“本末倒置”。

 

最最感觉不爽的就是开发效率狂底。大家想想为了实现一个功能,我们要手工写多少功能。Info类要手写,从数据模型转成Info类的方法要手工写,从Info类转成数据模型的方法要手工写,业务管理类的接口要写手工定义好,业务管理类的实现类要手工写好,当然业面的程序更不用说了,一个表20,30个字段是正常的,看看吧,一个功能要写多久,上周我写一个销售订单的功能,花了4天时间,而且还有很多代码和功能是参照别人采购订单的,复制了不少代码,修修改改才勉强完成。而且开发体验是相当的不爽。

 

因为手工写的地方太多,直接导致将来出问题的地方的机率会太多,一个地方考虑不到,重新编译调试要花多少时间,唉,无耐啊。

 

近段时间,我又在看了CSLA.NET的框架,感觉这个框架真是太好了,移动业务对象,分布式布署,特别还有一些代码自动生成的工具,感觉有了标准,代码自动生成,开发效率快,功能强大,开发体验绝对不一样。等下翻译一篇,代码自动生成文章给大家看看,昨天晚上试用一下这个软件,不是一般的强大。而且还是开源的,妈的,服了。

posted on 2008-11-09 21:58  leohuang  阅读(977)  评论(1编辑  收藏  举报