Какая структура данных лучше для сайта ASP.NET MVC - LINQ to SQL или NHibernate

Question

Мы собираемся приступить к разработке ASP.NET MVC и уже несколько лет используем нашу собственную инфраструктуру сущностей. Однако нам нужно поддерживать больше, чем способна наша структура сущностей, и поэтому я хотел бы получить некоторые мнения об использовании MVC с более надежной средой. Мы сузили выбор до NHibernate (с API-интерфейсами Fluent) или LINQ to SQL.

Какая среда лучше всего подходит для разработки в стиле MVC (я знаю, что SO использует LINQ to SQL)?

Если мы хотим поддерживать SQL Server, Oracle, MySQL - исключает ли это LINQ to SQL?

Answer 1

Как человек, который только что переключился с LINQ на SQL на (Свободно) NHibernate, вот несколько вещей, которые я заметил.

1. LINQ to SQL потребовалось так много времени, чтобы понять, как сделать эквивалент соединения-подкласса. После многих модификаций я где-то читал, что это невозможно. Он может отобразить наследование, только если ВСЕ столбцы находятся в одной и той же таблице. Это замечательно, если есть несколько столбцов, но в моем случае их много, и подклассы являются родителями для других подклассов и так далее. Почему я должен положить их все в одну таблицу ради моего ORM?

2. Опыт NHibernate был устойчивым (иногда слишком большим для небольших быстрых проектов), и хотя он знаком с ним по небольшим проектам, я чувствовал, что это может быть слишком много, и пошел по пути LINQ to SQL, так как мог генерировать DBML файл и будет в течение нескольких минут.

3. Свободное владение NHibernate. Берет лучшее из обоих миров (в моем случае). Я могу отображать, как я хочу, и иметь свою базу данных так, как я хочу, и мне не нужно идти на компромисс в моем домене или моделях данных. Также одно слово: Automapping ... глазурь на торте.

Мне пришлось бы пойти с другим ORM, как только я нашел ограничения и наткнулся на несколько трудностей с LINQ to SQL, но Fluent NHibernate сделал этот выбор легким, и я не думаю, что оставлю его, если что-то не придет это делает работу еще лучше.

Итак, как сказал Роб Скотт, вопрос в том, как вы абстрагируете свою область => модель данных? И вы начинаете с домена или базы данных? Насколько сложны отношения? Если у вас вообще есть какое-либо наследство, я бы сказал, просто перейдите на более богатую среду ORM и избавьте себя от горя.

Свободно владеющий NHibernate имеет одни из лучших документов, которые я когда-либо нашел, и есть так много поддержки, заметок, блогов и ресурсов, что ненавидеть себя меньше всего нужно ... ИМО! Я был запущен менее чем за 24 часа.

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

Лучшее указание на то, что инструмент не работает, - это когда вы должны РАБОТАТЬ с инструментом ... LINQ to SQL Я настраивал, читал технические документы, всевозможные сумасшествия и отказывался генерировать соответствующие запросы, прямо когда я Я был склонен изменить мою таблицу и домен, я сказал, позвольте мне дать Fluent водоворот, и я счастлив, что я сделал.

Удачи вам .. Извините за длинный ответ; все это было в последние пять или около того дней, так что, я думаю, я все еще догоняю: -)

Answer 2

Я добился большого успеха, используя Fluent NHibernate и внедрение зависимостей (в моем случае Ninject) с MVC.

Мне кажется, что любой зрелый ORM должен хорошо работать с MVC. Поскольку природа MVC (Модель / Представление / Контроллер) разделяет три проблемы, любой ORM должен вписаться в роль «Модель».

Answer 3

LINQ to SQL предназначен для SQL Server. Entity Framework также поддерживает некоторые другие базы данных.

NHibernate - хороший выбор. Вы можете использовать Castle ActiveRecord (он построен поверх NH), если вы работаете с приложением на основе данных или Sharp Architecture для руководства проектом.

Answer 4

Короткий (и не очень полезный) ответ заключается в том, что оба упомянутых вами ORM будут работать с MVC. Более длинный ответ заключается в том, что вы должны подумать о том, как вы хотите работать с объектами модели. Например, вы хотите заняться первичной разработкой объекта домена (в частности, подходом, управляемым доменом), или вы реализуете приложение типа «формы поверх данных», где вы можете создать слой доступа к данным из существующей базы данных? Как вы предпочитаете указывать сопоставления? Вы хотите использовать свободный интерфейс или довольны отображением файлов (или атрибутов объектов вашего домена)?

Это тип вопросов, которые необходимо изучить при выборе ORM, и они в основном не зависят от того, используете ли вы MVC или Winforms.

Answer 5

Entity Framework прекрасно интегрируется с MVC и поддерживает другие базы данных.

Answer 6

Entity Framework усложняет задачу. Используйте Fluent NHibernate, с шаблоном репозитория и инверсией управления в контроллерах.

NHibernate сделает многое проще. Недавно мы перешли с Entity Framework на Fluent Nhibernate, и Fluent NHibernate определенно является лучшим кандидатом.