MVC 3 с использованием хранимых процедур против Entity Framework 4

Question

Мы начинаем проект MVC 3 с Razor, и я не понимаю, какой подход выбрать, когда дело доходит до доступа / обновления данных.Я знаю, что у нас есть следующие варианты.

* Plain old ADO.NET
* LINQ to SQL
* NHibernate
* Entity Framework

Но я более склонен к использованию простого старого ADO.Net (так как я думаю, что это самый быстрый), я все равно буду использовать классы модели, но как только я получуданные из класса, я хотел бы пойти дальше и вызвать хранимую процедуру с помощью простого Ado.Net, а не с помощью методов EF Update.

Я хотел бы узнать ваше мнение, если есть какие-либо недостатки в этомподход по сравнению с использованием EF.

(Это будет общедоступный веб-сайт с большим трафиком!)

Answer 1

Кандидат спросил меня об этом в одном из интервью на этой неделе.Мы используем только хранимые процедуры и методы ADO.NET.Мы выбрали это потому, что обнаружили, что для создания высокопроизводительных приложений с ORM вам нужно быть экспертом в его использовании.Поскольку у меня нет экспертов по ORM, и я не планирую создавать / нанимать их, имеет смысл придерживаться стека, который мы знаем.

Я говорю, что вам нужно быть экспертом из-заспособ, которым ORM, такие как Hibernate (или NHibernate), создают отношения и, следовательно, SQL (в основном, объединения и т. д.).Я думаю, что ORM отлично подходит для небольших инструментов или сред RAD, где вещи ДОЛЖНЫ быть выполнены быстро, а также не могут жить вечно.Я думаю, что для крупных корпоративных приложений, где обслуживание и производительность более важны, чем ADO, безопаснее.Это не значит, что это не невозможно, но нужно быть внимательнее, чтобы обеспечить это.

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

Answer 2

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

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

Чтобы уточнить, в ответ на этот вопрос;

«поэтому вы думаете, что использование EF-маршрута намного эффективнее, чем просто вызов хранимого процесса с помощью Plain Old Ado.net при работе с большим объемом данных»

EF создает эффективный код, но вы можете столкнуться с ситуациями, когда вам нужно настроить код и / или базу данных, если вы видите проблемы с производительностью. Преимущество использования EF или другого ORM заключается в том, что вы станете более продуктивным разработчиком, это сэкономит ваше время и позволит вам сконцентрироваться на бизнес-правилах и т. Д., А не создавать доступ к данным вручную, используя ado. нетто

Answer 3

Я сделал общедоступный веб-сайт с расходом около 60 ГБ трафика в день (сайт работает только с 1 декабря по 24 декабря), и я выбрал Entity Framework с LINQ .

У меня не было никаких претензий к EF ... только сервер, который не мог обрабатывать такое количество пользователей, и мне пришлось поместить все изображения в Amazon S3 (используя Amazon .NET SDK), чтобы исключить чрезмерное количество пропускной способности в день.

EF кеширует вызовы, поэтому при получении того же объекта EF достаточно умен, чтобы не вызывать базу данных снова и не возвращать кешированный объект, все было сделано очень хорошо, и я должен сказать, что I был сдержан против EF, когда я начал проект, но в конце, это был ПОБЕДА !