#entity-framework-4.1 #enterprise-library
#entity-framework-4.1 #корпоративная библиотека
Вопрос:
Масштаб проблемы: я хочу использовать EF4.1 без каких-либо компромиссов со скоростью и надежностью блока доступа к данным корпоративной библиотеки, который я знаю и которому доверяю.
Благодаря множеству ссылок на Stackoverflow и блогам о настройке производительности EF я публикую этот способ, среди многих других, для использования EF4.1, который соответствует производительности блока доступа к данным ADO / Enterprise Lib (SqlDataReader).
Проект: 1. Нет linq к сущностям / динамическому sql. Мне нравится linq, я просто стараюсь использовать его в основном против объектов. 2. 100% хранимые процедуры и никакого отслеживания, никакого слияния и, самое главное, никогда не вызываются .SaveChanges(). Я просто вызываю процедуру вставки / обновления / удаления DbContext.StoredProcName(параметры). На этом этапе мы устранили несколько элементов быстрой разработки EF, но для меня достаточно того, как он автоматически создает сложный тип для вашего сохраненного процесса.
getString и подобные методы представляют собой AbstractMapper, который просто просматривает ожидаемые типы и преобразует datareader в тип. 
Так что, насколько мне известно, это рекорд, который нужно превзойти. Было бы трудно принять что-то, что, как я знаю, будет медленнее.
Это МЕДЛЕННЕЕ!!! Намного медленнее!
Это больше похоже на правду!! Распределение производительности Основываясь на моих результатах, это распределение производительности должно увеличить накладные расходы на отслеживание более чем на 1%. Я попробовал предварительно скомпилировать представления, и ничто не дало такого значительного прироста, как отсутствие отслеживания! Почему?? Может быть, кто-нибудь сможет вмешаться в это.
Итак, это не совсем справедливо по сравнению с корпоративной библиотекой, но я делаю один несвоевременный вызов базы данных для загрузки метаданных, которые, как я понимаю, загружаются один раз в пул приложений IIS. По сути, один раз в жизни вашего приложения.
Таким образом, я использую EF с автоматической генерацией хранимых процедур, и я использовал Linq в Edmx для автоматического импорта всех этих функциональных узлов edmx для сопоставления с объектами. Затем я автоматически создаю репозиторий для каждой сущности и движок.
Поскольку я никогда не вызываю SaveChanges, я не трачу время на сопоставление с сохраненными процессами в конструкторе. Это занимает слишком много времени, и это очень легко сломать и не знать об этом. Поэтому я просто вызываю процедуры из контекста.
Прежде чем я действительно внедрю это в свое новое веб-приложение для доставки критически важного медицинского оборудования, я был бы признателен за любые замечания и критические замечания.
Спасибо!
Комментарии:
1. Я использую это уже пару месяцев, и оно отлично работает, за исключением одной вещи. EF не поддерживает управление версиями или слияние. Если кто-то сомневается в EF, я считаю, что производительность не является главной проблемой.. EF обновляет весь файл .edmx, а также сохраняет расположения диаграммы x y в файле .edmx, что чрезвычайно затрудняет объединение файлов.. Я даже заметил, что одни и те же неизмененные xml-узлы отображаются на расстоянии тысяч строк от двух разных разработчиков. Code Smith решил эту проблему с помощью PlinqO, а также MS should.
Ответ №1:
Всего несколько замечаний:
Распределение производительности Основываясь на моих результатах, это распределение производительности должно увеличить накладные расходы на отслеживание более чем на 1%. Я попробовал предварительно скомпилировать представления, и ничто не дало такого значительного прироста, как отсутствие отслеживания! Почему??
Сообщение в блоге датировано 2008 годом и, следовательно, основано на EF версии 1 и EntityObject производных сущностях. В EF 4.1 вы используете POCOs. Отслеживание изменений в POCOs работает совсем по-другому. Особенно когда объект POCO загружается из базы данных в контекст объекта Entity Framework создает снимок исходных значений свойств и сохраняет его в контексте. Отслеживание изменений основывается на сравнении текущих значений сущности с исходными значениями snapshop. Создание этого моментального снимка, по-видимому, также дорого с точки зрения производительности и потребления памяти. По моим наблюдениям, это стоит не менее 50 процентов (время запроса без отслеживания изменений составляет половину времени запроса с отслеживанием изменений). Похоже, вы оценили еще большее влияние.
Проект: 1. Нет linq к сущностям / динамическому sql. Мне нравится linq, я просто стараюсь использовать его в основном против объектов. 2. 100% хранимые процедуры и никакого отслеживания, никакого слияния и, самое главное, никогда не вызываются .SaveChanges(). Я просто вызываю процедуру вставки / обновления / удаления DbContext.StoredProcName(параметры). На этом этапе мы устранили несколько элементов быстрой разработки EF, но для меня достаточно того, как он автоматически создает сложный тип для вашего сохраненного процесса.
Для меня это выглядит так, как будто вы по существу игнорируете некоторые из основных функций, для которых существует Entity Framework, и сомнительно, почему вы вообще хотите использовать EF для своих целей. Если ваша главная цель — иметь инструмент, который помогает материализовать результаты запроса в сложные объекты, вы могли бы взглянуть на Dapper, который фокусируется на этой задаче с учетом высокой производительности. (Dapper — это базовый ORM, используемый здесь в Stackoverflow.)
Несколько дней назад здесь был вопрос с отличными ответами о производительности EF. Теперь он перенесен в «Программисты»:
Комментарии:
1. Отличная информация! Спасибо за ваш пост. Я изучаю все это. Мой краткий опыт возврата dynamics из базы данных заключался в том, что мое приложение не прерывалось во время компиляции, когда я неправильно ввел свойство, а когда дело дошло до извлечения строго типизированных объектов, это было похоже на двойное сопоставление, и я пошел дальше. Я должен вернуться к Dapper и Massive. Я мог бы просто написать автоматическое создание кода для Enterprise. Опять же, отличная информация! Спасибо.