数据访问层的反射性能答案

【问题标题】：Reflection performance for Data Access Layer数据访问层的反射性能
【发布时间】：2010-10-25 12:59:42
【问题描述】：

我过去为一个项目创建了一个框架，它的功能之一是将数据库信息加载到我的业务实体类中（只有属性没有方法），然后从业务实体类加载到数据库中的参数集合要执行的存储过程。为此，我在该项目中使用 DB 归档信息和 SP 参数装饰了业务实体类，如下面的示例所示，并让框架使用反射加载实体或参数集合，因此我不必为维护生成新代码。
但是现在我正在创建一个新的更大的项目，当然要维护更多的代码，但是性能至关重要，我想知道是否值得对所有负载使用反射并保持代码更简单或实际生成所有代码和维护所有更改？
我进行了一些搜索，阅读了 MSDN 上的一些文档，但仍然发现了很多不同的意见，喜欢反射的人显示开销并没有那么糟糕，而其他人则说实际上最好远离反射

新应用的技术规格：
语言：C#
.Net 版本：3.5
应用程序类型：使用 C# 访问逻辑组件和数据访问层的经典 Web 窗体
数据库：SQL Server 2008
数据库抽象层：对数据库的所有访问都是通过存储过程和用户定义函数进行的。

示例代码：

    // Decorated class
[System.Serializable()]
public class bMyBusinessEntity{
    private Int64 _MyEntityID;
    private string _MyEntityName;
    private string _MyEntityDescription;

    [aFieldDataSource(DataColumn = "MyEntityID")]
    [aRequiredField(ErrorMessage = "The field My Entity ID is mandatory!")]
    [aFieldSPParameter(ParameterName="MyEntityID")]
    public Int64 MyEntityID{
        get { return _MyEntityID; }
        set { _MyEntityID = value; }
    }

    [aFieldDataSource(DataColumn = "MyEntityName")]
    [aFieldSPParameter(ParameterName = "MyEntityName")]
    public  string MyEntityName{
        get { return _MyEntityName; }
        set { _MyEntityName = value; }
    }
    [aFieldDataSource(DataColumn = "MyEntityDescription")]
    [aFieldSPParameter(ParameterName = "MyEntityDescription")]
    public string MyEntityDescription{
        get { return _MyEntityDescription; }
        set { _MyEntityDescription = value; }
    }
}


   // To Load from DB to the Object:
   using (DataTable dtblMyEntities = objDataSource.ExecuteProcedure(strSPName, objParams)) {
       if (dtblMyEntities.Rows.Count > 0) {
           DataRow drw = dtblMyEntities.Rows[0];
           oFieldDataSource.LoadInfo(ref objMyEntity, drw);
           return objMyEntity;
       }
       else
           throw new Exception(“Row not found!”);
  }

  // To Load from the Object to the DB
  oDataSource objDataSource = new oDataSource();
  IDbDataParameter[] objParams = objDataSource.GetProcedureParameters(strSPName);
  oFieldSPParameter.LoadInfo(objParams, objMyEntity);
  objDataSource.ExecuteNonQuery(strSPName, objParams);

【问题讨论】：

标签： c# performance reflection .net-3.5

【解决方案1】：

就我个人而言，如果数据访问要求需要大量事务（高度事务性的系统），我不会使用反射 - 您获得的灵活性最终会在运行时花费您（更多 comment on reflection here）。

我会选择 popular ORM solution 以尊重自定义解决方案。主要是您将受益于使用相同方法的更大社区（更容易获得设计建议、调试以及利用已知的性能调整）。

这通常还意味着访问支持新技术（例如 SQL Server 2008）的更新，因为它已发布 - 您无需承担这种负担或测试成本（除了直接实施）。

有一个 number of popular solutions 包括实体框架和 LINQ to SQL（在 .Net 3.5 中并且都支持存储过程），但也大量支持使用 CodeSmith 模板/网络层或更多的模板驱动方法例如，使用 NHibernate 或 Deklarit 的复杂解决方案。

我参与的最后一个大型解决方案以与您描述的方式大致相同的方式使用存储过程和函数，但是我们使用了企业库并使用手写工具生成了 DAL 访问类和数据传输对象。您可以使用与 MS Patterns and Practices 'Web Service Software Factory' 中使用的方法大致相同的方法，也可以使用任何模板驱动的方法。

【讨论】：

【解决方案2】：

与其滚动基本上是您自己的 ORM，我建议您切换到已建立的 ORM 之一，例如 NHibernate 或 Entity Framework。

直接回答你的问题，反射性能还不错，但我个人从来没有想过在大型项目中使用 ORM。

【讨论】：