Производительность отражения для уровня доступа к данным

Question

В прошлом я создал каркас для проекта, в котором одной из его функций была загрузка информации о базе данных в классы моих бизнес-сущностей (только свойства без методов) и из классов бизнес-сущностей в базу данных, загружающую коллекцию параметров хранимая процедура, которая будет выполнена. Для этого в этом проекте я украсил классы бизнес-сущностей информацией Filed DB и SP-параметрами, как показано в примере ниже, и позволил платформе загрузить сущность или коллекцию Parameters, используя отражение, поэтому мне не пришлось генерировать новый код для обслуживания.
Но сейчас я создаю новый и гораздо больший проект, конечно же, гораздо больше кода для поддержки, но там, где производительность критична, и мне было интересно, стоит ли использовать отражение для всей нагрузки и сохранить код намного проще или фактически сгенерировать весь код и сохранить все изменения?
Я провел некоторый поиск, прочитал некоторые документы по MSDN, но все же нашел много разных мнений, люди, которым понравилось размышление, показывающее цифры, что накладные расходы не так уж плохи, а другие говорили, что на самом деле лучше держаться подальше от размышлений.

Технические характеристики нового приложения:
Язык: C #
Версия .Net: 3.5
Тип приложения: классические веб-формы, обращающиеся к компонентам логики и уровню доступа к данным, также в 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, я бы порекомендовал перейти на один из установленных ORM, например NHibernate или Entity Framework .

Чтобы ответить на ваш вопрос напрямую, производительность рефлексии не так уж и плоха, но лично я никогда бы не подумал об использовании ORM, который я использовал для большого проекта.

Answer 2

Лично я бы не использовал Reflection, если требования к доступу к данным требуют большого количества транзакций (система с высокой степенью транзакций) - то, что вы получаете в гибкости, в конечном итоге стоит вам во время выполнения (подробнее комментарий к отражению здесь ).

Я бы выбрал популярное решение ORM , в отличие от пользовательского решения. В основном вы получите выгоду от более широкого сообщества людей, использующих те же подходы (легче получить совет по проектированию, отладку, а также воспользоваться известными настройками производительности).

Обычно это также означает доступ к обновлениям, которые поддерживают более новую технологию (например, SQL Server 2008) по мере ее выпуска - вы не носите этот бред или затраты на тестирование (кроме прямой реализации).

Существует ряд популярных решений , включая Entity Framework и LINQ to SQL (в .Net 3.5 и оба поддерживают Stored Procs), но также имеет большую поддержку подхода на основе шаблонов с использованием CodeSmith. шаблоны / сетевые ярусы или более сложные решения с использованием, например, NHibernate или Deklarit.

Последнее большое решение, которое я задействовал, использовало хранимые процедуры и функции почти так же, как вы описали, однако мы использовали Enterprise Library и создавали классы доступа DAL и объекты передачи данных, используя рукописный инструмент. Вы могли бы использовать тот же подход, что и в MS Patterns and Practices « Фабрика программного обеспечения веб-сервисов », или любой другой подход на основе шаблонов.