Миграция с NHibernate на Entity Framework 4.1?

Question

Я знаю, что этот вопрос может быть немного опасно задавать, но мне действительно нужно некоторое мнение по этому поводу.

У нас есть наша система, это веб-сайт (будет популярным веб-порталом, мы используем MVC3), и, прежде чем я остался здесь, остальные мои коллеги выбрали NHibernate в качестве своего решения OR Mapper, и они начали писать критерии запросов и такие ..

Сейчас команда ближе к подходу Linq, поэтому мы попытались написать запросы во встроенном поставщике Linq ... Дело в том, что ... он ужасно адаптирован - буквально вы не можете написать нетривиальный запрос и не получите Not supported exception ...

Мы решили, что это последний возможный момент, чтобы изменить наш OR Mapper на что-то более основанное на Linq, и мы, так как EF4.1 получили ультрадружественный вариант Code First, решили, что это то, что нам нужно.

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

Некоторые факты:

• В нашем проекте около 50 организаций
• У нас есть около 160 запросов, написанных в Criteria API (все охвачены в модульных тестах)
• Нам нужна поддержка композитов, наследования и многие-многие
• Проект будет в два раза больше, чем сейчас
• Мы не удовлетворены производительностью нашей базы данных
• Мы ненавидим то, как мы пишем запросы прямо сейчас!

Так что ... сейчас ... миграция это хорошая или плохая идея? Решит ли EF наши проблемы, сделает ли это нас счастливыми или этот шаг станет пустой тратой нашего времени?

Привет

Answer 1

Имейте в виду, что вы будете обменивать лучшую поддержку linq на худшие функциональные возможности отображения и иногда гораздо худшую производительность ( запросы наследования , нет запросов или пакетных команд , ...). Теперь вернитесь к доске и подумайте еще раз. Если вам сейчас не нравится производительность вашей базы данных, она вряд ли улучшится с EF.

Полагаю, уже немного поздно менять технологию - она ​​будет дорогой. Но в любом случае, если вы действительно хотите это сделать, почему бы не создать концептуальное доказательство, в котором вы берете какую-то действительно сложную отображаемую функцию с некоторыми сложными запросами и пытаетесь сначала сделать то же самое в коде EF? Вы можете протестировать то же самое просто в простом консольном приложении и сравнить как сопоставление, так и запросы + производительность.

Производительность, возможно, не является проблемой в данный момент, но в будущем вам действительно придется оптимизировать ее, и EF предоставит вам гораздо меньше возможностей для этого. Если вы хотите повысить производительность решения EF, вы очень часто возвращаетесь к собственному SQL и хранимым процедурам. Вы думаете, что у него будет больше опыта для написания запросов?

Answer 2

Я должен согласиться с @Ladislav, EF и LINQ - это хорошо, это просто работает по сравнению с NHibernate LINQ, однако генерирование SQL EF иногда довольно ужасно и не очень производительно, и вы будете вынуждены перекодировать сложные запросы в представления иSP и т. Д. Nhibernate также может попасть в эту ловушку, однако наличие множества различных опций является преимуществом, так как вы можете выбрать вишню, наиболее подходящую для ваших нужд.

Полагаю, вы пытаетесь сбалансировать следующее: -

1. переписать с использованием EF и затем преобразовать уродливый / медленный сгенерированный SQL в более производительные запросы к базе данных
2. использовать NHibernate и отбросить LINQ для чего-либо слишком сложного в Criteria / QueryOver / HQL

Каинда, прыгающая из одного ОРМ в другой, может быть похожа на прыжок со сковороды в огонь.У обоих есть свои сладкие пятна, оба обожгут ваши пальцы!

Answer 3

Лично я также сталкивался с проблемами с поставщиком linq для Nhibernate.

Однако я решил придерживаться NHibernate из-за его "правильного" генерирования SQL, общей производительности и расширяемости.

Последняя позволяет вам облегчить вашу СУБД с помощью кеша 2-го уровня на ваш выбор, такого как MemcacheD.Он сохраняет объекты в памяти (на сервере MemcacheD), извлекая / фиксируя их из / в СУБД, только если это необходимо.Также относится к скомпилированным SQL-запросам.

Answer 4

Ну, если честно, звучит так, как будто вы уже приняли решение. Я не уверен, что вы действительно спрашиваете здесь. Если вы заинтересованы в том, чтобы придерживаться NHibernate, вам следует задать конкретные вопросы о проблемах, которые у вас возникают.

По моему мнению, если ваша команда лучше знакома с EF, вам следует переключиться. Если нет, то я не уверен, что вы когда-нибудь узнаете, решит ли EF все ваши проблемы, если вы на самом деле не наметите конкретные проблемы, которые у вас возникают.

Answer 5

Вы пробовали Fluent NHibernate? http://fluentnhibernate.org/. Вы можете использовать LINQ с ним. Я использовал его в проекте, и он работал очень хорошо.