Чи варто використовувати Entity Framework?

На даний момент у нас є такий стек:

• VS 2005
• Веб-форми
• SQL Server 2005
• IIS 6

Ми плануємо перейти до цього:

• VS 2010
• MVC та веб-форми
• SQL Server 2008
• IIS 7

Моє питання: коли ми переходимо до MVC з VS 2010, чи слід використовувати Entity Framework (або інший ORM), мікро ORM (як Massive ) або просто звичайний SQL?

Усі навчальні посібники, які я читав про VS 2010, орієнтовані на використання Entity Framework для транзакцій з даними, але чи це буде в найближчому майбутньому (5+ років)?

Якщо це важливо, програми наших клієнтів можуть мати від 10 до 1000 активних користувачів.

Нещодавно я перейшов від використання вбудованих SQL запитів до використання EF, і ось що я знайшов:

Плюси

• Набагато швидше створити DAL (люблю не писати SQL-запити!)
• Набагато простіше в обслуговуванні
• Більше не потрібно пам’ятати, щоб проаналізувати мою інформацію перед тим, як скласти In-line-оператор sql, що означає менший шанс нападу ін'єкції SQL (звичайно, це все ще можливо в залежності від ваших запитів, але набагато рідше)

Мінуси

• Не можна охопити кілька баз даних ... принаймні, не просто
• Усі сутності (таблиці, представлення даних тощо) потребують первинного ключа
• Якщо ви хочете оновити один стовпець у 100+ необхідних таблицях стовпців (не мій дизайн таблиці), для оновлення вам доведеться знищити всі 100 стовпців. Або використовувати Збережену процедуру.
• У мене виникли проблеми з деякими значеннями за замовчуванням, визначеними на сервері SQL, і не потрапляє в модель сутності після того, як додається нова запис. Зазвичай це з обчисленими значеннями або значеннями, що додаються в триггер INSERT
• Іноді запити SQL погано пишуться і виконуються повільно. Якщо у вас є повільний запит, запустіть SQL-слід, щоб побачити, що робить EF. Можливо, ви можете переробити цей запит як SP або View. Але це трапляється не так часто.
• У мене виникло декілька проблем із спробою створити асоціацію між таблицями, у яких немає зовнішнього ключа, визначеного в SQL Server. Зазвичай це тому, що я намагаюся створити 1:0-1відносини, коли EF хоче використовувати1:0-*

Я, однак, не фахівець з EF, тому, певно, я пропустив щось. Це лише ті пункти, з якими я знаю, з якими я стикався в минулому при переході від вбудованого SQL до Entity Framework. Я радий, що перемкнувся, але були випадки, коли я дуже ненавидів EF через його химерність.

Entity Framework - це інструмент підвищення продуктивності праці. Якщо у вас немає вагомих причин цього не робити (EG ви перебуваєте на SQL 2000 або не маєте часу нарощувати технологію), тоді використовуйте найкращі інструменти, які у вас є.

Попри це, я вважаю, що поняття Entities дуже добре перекладаються на модель моделі MVC. Хоча стосунки з моделями та таблицями у відносинах 1: 1 є поганою практикою, мислення з точки зору організацій має тенденцію створювати чисті конструкції, легко читати код (особливо з LINQ).

Microsoft Entity Framework активно підтримується Microsoft. Ніхто не має магічного кришталевого кульки, щоб сказати, що "підтримка триватиме X років". Я не бачу причин вважати, що суб'єкт господарювання помре в найближчі 5 років.

Іншим потенційним рішенням є використання альтернативної бібліотеки Entity Framework, яка не є тією, що постачається з VS У мережі є декілька.

Концепція фреймворку Entity / 3 шарів існувала вже деякий час і працювала з декількома спеціалізованими бібліотеками, як і багато інших розробників, перш ніж Microsoft випустила власну "офіційну" структуру.

Плюси

Майте переваги структури Entity (DAL), не заважаючи постійним змінам бібліотек / змін у Microsoft.

Додавання функцій до бібліотеки, які, можливо, недоступні для існуючої офіційної бібліотеки, як-от використання декількох марок dtabase.

Мінуси

Доводиться підтримувати бібліотеку чи інструменти. Дуже звичайно мати інструмент генератора коду Entity для генерації enitites.

Ви повинні прийняти архітектурне рішення на основі проблеми та існуючого рішення. Як і у будь-якої технології, є переваги і недоліки.

Я особисто використовую структуру суті для нової розробки, але не переписую працюючий існуючий код. Потім ви отримуєте швидкість для майбутнього делелопменту, але не потрібно вкладати багато часу в перетворення коду. Мінусом цього підходу є те, що він зменшує сталість.

У вашій ситуації я б точно використав Entity Framework, я виявив, що він добре працює з MVC.
Ось кілька справжніх причин та покажчиків.

• Linq - це приємно користуватися, а також затримка виконання також надзвичайно корисна.
• Ви можете генерувати свої моделі (однак, коли ви використовуєте mvc, я б рекомендував використовувати моделі перегляду спільно з моделями даних, це полегшує перевірку та прив'язку моделі, якщо ви скористаєтеся таким підходом, використовуючи автоматичний автоматичний перемикач змін на ваш модель даних).

Однак ви можете дізнатися про ряд речей про використання ORM.

• Що контекст робить для вас (відстеження сутності)
• Що контекст слід використовувати як одиницю роботи
• Пам'ятайте, що стосується паралельності, EF може сказати вам, коли ваш об’єкт застарів, але це може бути складним, якщо ви хочете правильно обробляти паралельність за запитами (як вам потрібно дотримуватися часову позначку чи щось).

Що слід врахувати

• Тригери та ORM не працюють разом, замість цього використовуйте події ORM.
• Переконайтеся, що у всіх ваших таблицях є кнопки прогляду.

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

• Конвенції означають, що вам не потрібно реєструвати відображення чи класи під час зміни бази даних.
• Це зручніше розміщувати валідацію та іншу логіку в моделях.
• Ви можете використовувати генератор коду, щоб зробити їх, якщо у вас є величезна база даних.