Замена NHibernate на LINQ to SQL или LINQ to EF

Question

У нас есть отличный проект, который использует NHibernate в качестве ORM.Мы хотим перейти на L2S или L2EF.Можем ли мы сделать все, что мы делаем с помощью NHibernate?

Вы предлагаете нам эту работу?В чем преимущества и недостатки этой работы?У этих двух ORM есть общие возможности?

Примечание: наш проект написан на C #.

Answer 1

Если вы собираетесь перейти, я настоятельно рекомендую не использовать linq to sql, поскольку будущее очень неясно .Что касается различий между NHibernate и linq для сущностей, у Ayende Rahien есть несколько постов в блоге, касающихся различий.

1. nhibernate против структуры сущностей 4.0
2. в ответ на то, как ef лучше
3. что можетef 4.0 сделать то, что nhibernate не может

К вашему сведению: Айенде является членом команды NHibernate.

По второму вопросу.Было бы трудно предложить выполнить эту работу, не зная, как NHibrinate подводит вас.В зависимости от состояния и размера продукта мне было бы очень трудно рекомендовать изменить составную часть приложения, например ORM, без очень продуманных причин.

В любом случае, NHibrinate является очень солидным продуктом и имеет большой опыт работы в сообществе открытых исходных кодов .net.С другой стороны, у Microsoft есть история внедрения решений Data Access / ORM и быстрого отказа от них.

Answer 2

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

В NHibernate появятся функции, которых нет в других инструментах ORM (компоненты сразу приходят на ум), поэтому вам придется искать обходные пути или перепроектировать классы или структуры таблиц для компенсации изменений.

Должны ли вы сделать эту работу? Я бы порекомендовал нет.

Answer 3

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

Да, вы сможете делать все, что вы делаете в настоящее время с NHibernate, с помощью структуры сущностей(хотя не совсем уверен насчет LINQ to SQL), но не переключайтесь ради фреймворка.Это похоже на замену шин на вашей машине через неделю после их покупки - может быть интересно иметь новые блестящие шины, но в конце концов, они просто шины.Шины, которые у вас сейчас есть, просто хороши - возможно, есть другие области применения, которые могли бы получить больше пользы от времени, отведенного для этого проекта?

Answer 4

Linq to SQL поддерживает , а не где-либо рядом со всем набором функций NHibernate.Я использую Linq для SQL и думаю, что это здорово, но он предназначен для использования в качестве прямого сопоставления 1: 1 с базой данных.Это немного меньше настоящего ORM, чем NHibernate, и скорее решение для доступа к данным.Среди прочего, отсутствует:

• Свойства компонента;
• Отображение "многие ко многим";
• Автоматическое отображение (хотя инструменты дизайнера в основном компенсируют это);
• Поддержка нескольких платформ (Linq to SQL действительно поддерживает только SQL Server и SQL CE)
• Отображение нескольких таблиц в один класс

Entity Framework 4 - этоочень близок к NHibernate с точки зрения его набора функций, и вы должны быть в состоянии сделать большую часть того, что вы в настоящее время можете сделать в NHibernate.Но я искренне согласен с остальными, которые советуют не менять свой ORM просто ради удовольствия;фактическая семантика сильно отличается, и вы в конечном итоге пройдете много циклов боли и исправлений.

Answer 5

NHibernate позволяет вам реализовать свою логику, не вызывая DAL все время (« постоянное невежество »). Это возможно, потому что NH сравнивает экземпляры в памяти и автоматически обнаруживает изменения.

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

При правильном использовании NHibernate вы пишете свое приложение, как будто не было никакой устойчивости (скажем, до 80%) и все еще получаете высокую производительность. Поскольку Linq to Sql или EF не предоставляют эту возможность (AFAIK), я не представляю, как вы можете перенести в нее большое приложение. Ваш код должен будет вызывать DAL все время, в настоящее время это не так.

Answer 6

По какой причине вы хотите мигрировать?Существующее решение не работает?Это проблема производительности?Я бы рекомендовал уделить немного времени, чтобы убедиться, что вы понимаете, в чем проблемы, производительность или нет, и сосредоточиться на них.С правильными индексами в вашей базе данных и использованием выборок NHibernate, таких как пакетная обработка, вы можете обнаружить, что ваши проблемы решаются без переписывания.

Кроме того, рассмотрите LinqToNHibernate как первый шаг.Синтаксис Linq будет таким же, как тот, который вы в конечном итоге используете.В этом красота Линка.