Что бы вы выбрали для своего веб-приложения ASP.NET; nHibernate, Linq или SubSonic

Мы используем ADO.NET Entity Framework на довольно активном сайте (10 000 посещений в день). Для нас это было солидно. Отсутствие ленивой загрузки раздражает, но заставляет задуматься о переходе к базе данных.

LINQ - отличный выбор. Он используется здесь в Stackoverflow, а в моем текущем проекте мы используем LINQ для доступа к данным.

SubSonic в настоящее время с большим успехом используется во всех наших веб-приложениях. За считанные минуты вся ваша база данных может быть создана с нуля и готова к использованию в вашем приложении. У Роба Конери, создателя SubSonic, есть несколько отличных веб-трансляций, в которых подробно описывается процесс настройки битов SubSonic в веб-приложении, а также несколько интересных демонстраций, которые помогут вам начать работу. Проверьте SubSonic Project.

Я использую LLBLGen Pro для своего ORM около года, и это сработало довольно хорошо. Хотя я не использовал SubSonic, мне сказали, что они похожи. С нуля он может создать уровень доступа к данным из вашей базы данных и быть готовым к использованию всего за пару минут. Здесь есть небольшая кривая обучения, по крайней мере, для меня, но файлы справки предоставляют достаточно информации, чтобы помочь вам почти во всем, с чем вы столкнетесь. Приложение можно без проблем использовать в том виде, в котором оно установлено, но оно также поддерживает обширные настройки (может быть, слишком много?).

Hibernate для проектов Java, но, несомненно, LINQ для .Net. Зачем добавлять внешнюю зависимость, если у вас есть встроенный LINQ?

Я бы также выбрал LINQ, хотя должен признать, что у LINQ to SQL есть проблемы с многоуровневостью. Я прочитал много статей о LINQ to SQL, и все они предполагают, что он в основном создан для приложений RAD.

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

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

Другой вариант - Замок ActiveRecord. Он реализует Шаблон проектирования Active Record поверх NHibernate, а также снимает большую часть проблем с настройкой (например, с его настройкой isWeb) и отображением.

Мой опыт работы в экосистеме Microsoft:

Я использовал Linq2Sql в нескольких проектах, и я столкнулся с проблемой «наслоения», о которой упоминает azamsharp.

Не то чтобы это сильно помогло бы, если вы твердо настроены на отправку POCO обратно на свой уровень логики или пользовательского интерфейса, но реализация шаблона репозитория немного помогает с этой неприятной проблемой разделения на слои и разделения проблем.

Хороший базовый репозиторий Impl

ADO.Net Entity Framework дает вам некоторые преимущества для всего, что использует сложную семантику, такую ​​как голосование или статистика (в основном, любой объект домена, который должен отображаться или работать с ним иначе, чем он представлен в базе данных). Это может упростить вашу бизнес-логику / уровень доступа к данным за счет сложного извлечения данных.

Обзор ADO.Net Entity Framework

Надеюсь, это поможет!

Я бы использовал NHibernate. Для меня Persistence Ignorance является одним из основных продающих понтов, а отсутствие привязки к базе данных - другое. Entity Framework глубоко ошибочен, это больше, чем просто отсутствие отложенной загрузки. EF и LINQ2SQL - это новые технологии, тогда как NHibernate очень зрелый и претерпел гораздо больше действий.

Еще одна хорошая вещь в NHibernate - это возможность переключать базы данных без редактирования вашего. Я использую это для интеграционных тестов, которые выполняются локально, запускать их на SQLite, а затем на SQL Server на сервере CI.

Мне нравится SubSonic, поскольку его довольно легко настроить и создать DAL. Реализация не является полноценной ORM, поскольку она создает только класс для каждой таблицы. Возможность использовать хранимые процедуры компенсирует, когда вам нужно составить объекты, которые являются результатами объединений. Опять же, SubSonic призван быть функциональным, поэтому он поможет вам быстро достичь целей проекта.

Тем не менее, вы не можете использовать SubSonic для «компоновки объектов» - нет файла конфигурации, который описывает отношения между классами. База данных по-прежнему определяет, как вы формируете свое решение.

Меня не особо интересует SubSonic. Мне это кажется очень тонким инструментом DAL. С SubSonic я все еще набираю много строковых литералов, что, похоже, меня не интересует. Лично я предпочитаю LLBLGen:

http://www.llblgen.com/defaultgeneric.aspx

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

http://weblogs.asp.net/FBouma/