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

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

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

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

Ответ 1

У меня был большой успех с использованием Fluent NHibernate и инъекции зависимостей (Ninject, в моем случае) с MVC.

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

Ответ 2

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

LINQ to SQL потребовалось столько времени, чтобы выяснить, как сделать эквивалент подкласса join. После многих модификаций я где-то читал, что это невозможно. Он может отображать только наследование, если ВСЕ столбцы находятся в той же таблице. Это здорово, если есть несколько столбцов, но в моем случае есть тонны, а подкласс - родители для других подклассов и так далее. Почему я должен помещать их все в один стол ради моего ORM?
NHibernate из опыта был надежным (иногда слишком много для небольших быстрых проектов) и, хотя он был знаком с ним через небольшие проекты, я чувствовал, что это может быть слишком много, и пошел по пути LINQ к SQL-SQL, поскольку я мог сгенерируйте файл DBML и заходите в течение нескольких минут.
Свободный NHibernate. Принимает лучшее из обоих миров (в моем случае). Я могу сопоставить способ, которым я хочу, и иметь свою базу данных так, как я хочу, и не компрометировать в своих доменах или моделях данных. Также одно слово: Automapping... обледенение на торте.

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

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

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