Является ли Entity Framework избыточным для веб-приложений?

Question

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

До сих пор я разрабатывал n-уровневые решения с использованием ADO.NET и хранимых процедур с помощью класса SqlHelper.Для более крупных приложений я использовал Enterprise Library (2.0).

Я хотел бы перейти к подходу на основе ORM и начинаю изучать LINQ, а также переходить с ASP.NET Web Forms на ASP.NET MVC.Я не хочу идти с LINQ-to-SQL. Вопрос не в том, требуется ли ORM, а в том, является ли ORM Entity Framework избыточным для такого проекта.Я не возражаю против кривой обучения, если она оправдана для поставленной задачи.

Что касается "перебора", я хотел бы знать, если:

• EFбыстрее, чем кто-то с правильными навыками кодирования запросов вручную
• EF приводит к ненужному раздутию кода
• EF излишне экранирует разработчиков от деталей уровня кода их запросов
• LINQ-to-Entities подходит для проектов такого размера

На самом деле, если кто-то считает, что ORM избыточен для такого проекта, я хотел бы услышать причины этого.

Answer 1

EF не является излишним для веб-приложений.

Я не согласен со многим из того, что сказано в вашей статье.Я согласен с тем, что разработчики должны обладать хорошими навыками работы с SQL, НО ORMS отлично справляются с задачей более быстрого выполнения работы разработчиков.

• Скорость ORMS - они становятся все лучше и лучшепозволяют вам вызывать SP или изменять запросы, чтобы получить максимальную скорость при необходимости.Существуют также отличные профилировщики для мониторинга производительности ORM, такие как EFProf .

• Замедляет процесс кодирования - Действительно !!!Однажды узнав, что это ускоряет его.

• Разработчикам, которым необходимо знать SQL - я согласен.Однако ORMS, особенно с синтаксисом LINQ, часто позволяют разработчикам писать более сложный SQL, чем они могли бы самостоятельно.

• Разработчики уже пишут эффективные запросы - REALLLYYYY !!!!Просто спросите администратора его / ее мысли!Я думаю, что думаю, но все остальные тоже.Вижу проблему.: -)

• Code Bloat - приходится не соглашаться, особенно с теми, которые имеют LINQ .... Это часто делает код более читабельным и часто уменьшает количество строк.

• Забудьте о LINQ - этот корабль уже отплыл.LINQ Rocks !!!!Пойти с этим или остаться позади.Это не просто используется в ORMS.Его можно использовать против массивов, объектов, XML, файлов, твиттера, и этот список можно продолжать и продолжать .... Познакомьтесь с LINQ.

В статье говорится о некоторых изВдохновение последних разработок из MS как Ruby on Rails.В ROR есть ORM на основе Active Record .....

ORMS хороши.Их не нужно использовать везде и всегда, но они хороши и должны учитываться.

Answer 2

Хотя это общий ответ, будьте осторожны с любым мнением, которое имеет следующие комментарии:

«Инструмент X воняет, я пишу инструментом Y и могу сделать это быстрее, чем инструментом X».

Или, конечно, говорящий на латыни лучше говорит на латыни.

Answer 3

EF имеет кривую обучения, но все новое имеет.EF не является излишним, но, как написано в любой системе, используйте правильную технологию для правильного проекта.

Answer 4

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

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

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

Конечно, есть те, которые будут очень сильно не согласны. Нет проблем!

Я знаю разработчиков, которые начинали любить его, а теперь нет. Но я также знаю разработчиков, которые любят EF и клянутся им.

За эти годы я использовал EF, LINQ to SQL, NHibernate и другие.

Лучший совет: попробуй. Приходите к своему собственному заключению.

(Раскрытие: я автор цитируемой вами статьи).

Answer 5

Глядя на статью, первое, что я увидел бы и не согласился, это:

Я твердо верю, что современные веб-разработчики должны:

• Любить базы данных.

• Написание высокоэффективных запросов.

• Минимизация кода.

• Разработка самоочевидных пользовательских интерфейсов.

• Работа быстро.

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

Здесь Entity Framework вступает в игру.Он считается инструментом быстрой разработки приложений (как и большинство других ORM).Эти инструменты созданы специально для того, чтобы вы могли больше сосредоточиться на том, как выполнять требования пользователя, а не на том, как правильно написать запрос.

С учетом сказанного я бы также сказал, что наивное использование инструмента может быть опасным.Когда вы используете Entity Framework, вы все равно должны знать о последствиях использования графа объектов, который вы запрашиваете.

Это далеко не излишне, инструмент очень прост в использовании и прост в освоении.Я бы сказал, что проще «исправить» Entity Framework, чем исправлять необработанный SQL-запрос и набор транзакций ADO.

В небольших проектах моя базовая рекомендация почти всегда идет с каким-то типом ORM.С корпоративными приложениями вы должны быть немного осторожнее, и это полностью зависит от бюджета: -).

Answer 6

Это на самом деле зависит от сложности вашей модели данных, а не от типа приложения.

Если у вас относительно простая модель данных, то EF может быть излишним (если вы еще этого не знаете). Linq-to-SQL может быть лучшим выбором (меньшая кривая обучения, хотя он также имеет ограничения, такие как отсутствие сопоставления «многие ко многим»).

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

Статья, на которую вы ссылаетесь, указывает на то, что ORM в целом плохие, а не просто EF. Когда он сталкивается со своими пунктами, он, кажется, в какой-то степени отступает от них. Похоже, что он пытается оправдать общую концепцию (что новым разработчикам нужно изучать низкоуровневое кодирование, особенно SQL, прежде чем переходить к высокоуровневым фреймворкам), придумывая сомнительные моменты.

Answer 7

Определенно не излишество.Продолжай и используй EF.