Entity Framework 4.1 и максимальная производительность блока приложений корпоративных данных

Объем проблемы: я хочу использовать EF4.1 без каких-либо компромиссов в отношении скорости и надежности блока доступа к данным Enterprise Library , который я знаю и которому доверяю .

Благодаря множеству ссылок на Stackoverflow и блогам о настройке производительности EF я публикую этот способ среди многих, чтобы использовать EF4.1, который соответствует производительности блока доступа к данным ADO / Enterprise Lib (SqlDataReader).

Проект: 1. Нет linq для Entities / dynamic sql. Я люблю linq, просто стараюсь в основном использовать его против объектов. 2. 100% хранимые процедуры и без отслеживания, без слияния и, самое главное, никогда не вызывайте .SaveChanges (). Я просто вызываю процедуру вставки / обновления / удаления DbContext.StoredProcName (params). На данный момент мы устранили несколько элементов быстрой разработки EF, но мне достаточно того, как он автоматически создает сложный тип для вашей хранимой процедуры.

SqlTableRow CountThe ClassThe Mapper GetString и аналогичные методы представляют собой AbstractMapper, который просто перебирает ожидаемые типы и преобразует средство чтения данных в тип. The SprocEnterprise Lib result

Так что, насколько я понимаю, это лучший показатель. Было бы трудно принять что-то, что, как я знаю, будет медленнее.

EF result one

Это МЕДЛЕННО !!! Намного медленнее!

EF Result TWO

Это больше похоже на то !! Круговая диаграмма производительности На основании моих результатов, что круговая диаграмма производительности должна увеличить накладные расходы на отслеживание более чем на 1% Я пробовал предварительно скомпилировать представления, но ничего получил такой же импульс, как отсутствие отслеживания! Почему?? Может быть, кто-нибудь сможет вмешаться в это.

Таким образом, это не совсем честно по сравнению с Enterprise Lib, но я делаю один бессрочный вызов базы данных, чтобы загрузить метаданные, которые, как я понимаю, загружаются один раз для каждого пула приложений IIS. По сути, один раз в жизни вашего приложения.

EF result Three

Я использую EF таким образом с автоматической генерацией хранимых процедур, и я использовал Linq для Edmx , чтобы автоматически импортировать все эти функциональные узлы edmx для сопоставления с сущностями. Затем я автоматически создаю репозиторий для каждой сущности и движка.

Поскольку я никогда не вызываю SaveChanges, я не трачу время на отображение сохраненных процедур в дизайнере. Это занимает слишком много времени, и очень легко сломать это, не зная об этом. Поэтому я просто вызываю процедуры из контекста.

Прежде чем я на самом деле реализовал это в моем новом веб-приложении для доставки критически важного медицинского оборудования, я был бы признателен за любые замечания и критические замечания.

Спасибо!

5
задан TheDev6 12 November 2011 в 08:27
поделиться