Дорожная карта для лучшего доступа к данным для приложения asp.net MVC

Question

У меня довольно маленькое приложение asp.net MVC 2 для поддержки / расширения.В настоящее время он использует рукописные хранимые процедуры + код приложения для доступа к данным.По сути, он загружает данные и переносит их в POCO.

Текущая реализация утомительна.Особенно, когда мне нужно добавить новое свойство - не говоря уже о добавлении нового класса / таблицы для выполнения CRUD.Приложение имеет отдельное кэширование, которое также сложно поддерживать - и это привело к нескольким дефектам.Я также хотел бы избавиться от этого.

Я начал думать о переключении на какой-нибудь инструмент ORM, например, NHibernate или Entity Framework.

У меня очень ограниченный опыт, когда дело доходит до ORMили доступ к данным в целом.Каковы лучшие практики в этой ситуации?Что я должен принять во внимание, прежде чем перейти на NHibernate / Entity?А как насчет минусов?

Answer 1

Я использовал как NHibernate, так и Entity Framework.

В работе мы использовали Entity Framework, потому что было проще убедить других использовать его, а не приложение с открытым исходным кодом.

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

В настоящее время в EF я сталкиваюсь с проблемой, когдаЯ не могу использовать полнотекстовый поиск на сервере SQL, потому что EF не поддерживает это.Я мог бы сделать прямой запрос через контекст, но я бы предпочел использовать табличные функции, которые очень легко реализовать в Linq2, но по какой-то причине команда EF не дошла до этого.

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

Создайте свое приложение так, как будто вы планируете переключать ORM в будущемпотому что, как сказал ваш первый комментатор, вам, вероятно, придется.Ваши доменные объекты должны быть POCO, они не должны иметь постоянных знаний

Купить EntityFramework Prof или NHibernate Prof (это поможет вам оптимизировать запросы)

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

Используйте Code first EF или Fluent Nhibernate, сопоставления прерываются во время выполнения, свободно разбиваются во время компиляции.

Использование Linq2Entities или Linq2Nhibenate, строго типизированные запросы упрощают жизнь примерно в 80% случаев.

Не имейте ни одного гигантского XML-файла, такого как EDMX, который ужасно сложно контролировать версиями.Остерегайтесь генерации кода, это помогает ... но это также опасно во многих ситуациях.

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

Answer 2

«Лучшая практика» - одно из моих наименее любимых слов - оно часто используется, чтобы придавать большее значение мнению, чем оно действительно заслуживает ...

Сказав это ...

Сначала выберите стратегию доступа к базе данных; ORM является действующим отраслевым стандартом де-факто, и вы определили лидеров; см. эту тему для сравнения.

Различные методологии доступа к базе данных обмениваются разными вещами. Тот, который ваше приложение использует в настоящее время, предоставляет подробный контроль над запросами и способом их отображения в вашем домене, но за счет большого количества ручного кодирования. Это, вероятно, обеспечит лучшую производительность и большую гибкость; некоторые утверждают, что это проще всего поддерживать, потому что разработчикам не хватает «магии», чтобы заставить их задуматься.

Решения ORM обмениваются производительностью и контролем для более быстрой разработки и (некоторые утверждают) более простого обслуживания. Существует кривая обучения, и промежуточный уровень «магии» может усложнить выявление некоторых проблем - классический анти-паттерн с ORM - «загрузка всей базы данных в память», но проблемы с производительностью также могут быть сложными для отладки. С другой стороны, вы уменьшаете общий объем кода и значительно упрощаете создание простых операций CRUD. Разработчикам с опытом работы в ORM будет проще поддерживать их; разработчики, которые плохо знакомы с ORM, должны будут изучить структуру.

В целом, я думаю, что индустрия переходит на ORM для приложений, которые не предъявляют экстремальных требований к производительности; это становится мейнстримом, и большинство разработчиков, с которыми мы беседуем в эти дни, имеют опыт работы с ORM. Тем не менее, кривая обучения может быть довольно крутой, и есть определенная курица и яйцо - какой ORM вы выбираете, не имея опыта их всех? FWIW, я думаю, что ответ Стивена Лейси на деньги там ...

То, что вы предлагаете, это в основном рефакторинг. Я бы порекомендовал процесс по следующим направлениям:

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

Я бы приложил как минимум столько же усилий для создания тестов, как и для самого рефакторинга, - и я бы не стал призывать добавлять новые функции, пока вы не замените текущую реализацию.

Убедитесь, что ваши тесты включают тестирование производительности и масштабируемости.