Question

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

新应用的技术规格：
语言：C＃
.Net版本：3.5
应用程序类型：经典Web表单访问逻辑组件和数据访问层也在C＃中数据库：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);

Answer 1

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

要直接回答你的问题，反思表现并不是那么糟糕，但我个人从未想过使用我在一个大型项目中使用的ORM。

Answer 2

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

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

它通常意味着访问支持更新技术（例如SQL Server 2008）的更新，因为它已经发布 - 您不会佩戴该负担或测试成本（直接实施除外）。

有一个number of popular solutions包括实体框架和LINQ to SQL（在.Net 3.5中，并且都支持Stored Procs），但是对使用CodeSmith模板/ Net Tiers的模板驱动方法也有很多支持，例如，使用NHibernate或Deklarit的更复杂的解决方案。

我参与使用的存储过程和函数的最后一个大解决方案与您描述的方式非常相似，但我们使用Enterprise Library并使用手写工具生成DAL访问类和数据传输对象。您可以使用与MS模式和实践'Web Service Software Factory'可能使用的方法相同的方法，或任何模板驱动的方法。

数据访问层的反射性能

2 个答案: