学步园

在《关于数据访问模式（一）—— 数据访问模式的重要性》 一文中，作者提到他们的团队使用EJB时，性能极其的糟糕，然后不得不求助于存储过程。但ORM产品的性能到底如何呢？我在网上搜索了一番，没有找到相关的测试报告。
这几天公司对ORM开发做评估，自然提到性能，这样我们就自己做了一个LoadTest，具体的测试结果是不能说的，这是公司的东西，但我可以告诉你ORM（XPO）大概是DataSet（强类型DataSet）性能的1/3不到。
经理对这个测试结果甚微不满，偶狂解释不要拿ORM的弱势跟表模式的比较啊，经理不予理睬。

于是我开始想解决方案。
问题：
1、我们知道ORM都是在运行时分析实体的Metadata信息，然后自动构建SQL语句，稍微好一点的ORM都会第一次获取Metadata后就缓存一份，这样还是可以快一些的。
2、但是数据Select出来之后，填充进去的时候还是要根据结构慢慢填充，不像DataSet就一个二维结构，填充简单且贼快。
3、Metadata在ORM中都缓存了，但是Select、Insert、Update和Delete语句缺都是运行时构建的，而我们知道强类型的DataSet在设计时就帮你构建了，那性能当然没有的说了。

解决方案：
办法当然是向优秀者学习，我想象中我们的ORM实体和实体的Metadata还是老办法，但是数据访问层就不再运行时构建了，而是设计时自动创建代码，就像我们强类型的DataSet一样。
生成的代码可能像这样：

    internal class CustomerDataService {
        private IDbCommand cmdSelect_Customer;
        private IDbCommand cmdInsert_Customer;
        private IDbCommand cmdUpdate_Customer;
        private IDbCommand cmdDelete_Customer;

        private IDbDataParameter parSelect_CustomerId;

        public CustomerDataService() {
            自动构建所有Command#region 自动构建所有Command

            #endregion
        }

        public Customer Read(int id) {
            parSelect_CustomerId.Value = id;
            IDataReader read = cmdSelect_Customer.ExecuteReader();
            try {
                if (read.Read()) {
                    Customer data = new Customer();
                    data.Oid = read.GetInt32(0);
                    data.Name = read.GetString(1);
                }
                else {
                    throw new NotFindException(id);
                }
            }
            finally {
                if (read != null && !read.IsClosed) {
                    read.Close();
                }
            }
        }
    }

偶就不信这样的代码性能还会比他DataSet差。

面带微笑，极度想象中