最近有幸参与了一个生管软件的SAAS开发，也做了两周的编程。总体感觉有可取之处，但更多的是感觉运行速度慢，开发效率低。下面就简单分析一下。
软件采用.net 3.5，开发工具用VS2008，数据库sql 2005。系统也进行了分层，有ASP.NET表现层，业务管理层，数据访问层，数据库本身也算一层吧。<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
在表现层和业务层之间用了Microsoft.Practices.Unity工具，用于在表现层调用业务管理层时，能实现一个接口转换。在表现层，编程时使用业务管理层的对象所对应的接口，程序运行时，Unity工具会实现真正业务对象的调用。表现层和业务层之间传递数据的是所谓的“域模型”，一般命名成xxxInfo类，但我感觉更象个“实体类”。
数据访问层是通过ADO.NET Entity Framework，微软最新推出的一个所谓ORM的工具，当然，在VS中拖入表结构，再设置一些实体模型，数据模型的对应关系，就能全部生成数据的访问，代码几乎不用写。
业务层，业务管理对象，一般命名成ManageXXX主要实现查询，新增，修改，删除（CRUD）的包装，如新增或修改操作时，先调用数据库成的EF创建一个EF的实体模型对象，如果是新增就创建一个新的，如果是修改就根据ID捞一个，再将UI层包装过的Info对象，字段一一映射到实体模型对象，调用EF的SaveChanges方法。当然取数据时，是从EF实体模型一一映射到Info对象。
总体的架构就是这样。我以个人感觉来说说这样做有什么不好。
数据库EF是微软刚推出的技术，看了MSDN，感觉是不错，但真正用起来，我感觉没多少人用得好，大家还是对传统的ADO技术比较熟悉，一些特别的功能实现上，在业务管理类中，用了一些EA LINQ的语法，EA 实体语法，EA的SQL用得不多，访问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的框架，感觉这个框架真是太好了，移动业务对象，分布式布署，特别还有一些代码自动生成的工具，感觉有了标准，代码自动生成，开发效率快，功能强大，开发体验绝对不一样。等下翻译一篇，代码自动生成文章给大家看看，昨天晚上试用一下这个软件，不是一般的强大。而且还是开源的，妈的，服了。
758
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
