Почему бы не использовать классы, сгенерированные EF, в больших проектах?

Question

Я собираюсь использовать Entity Framework 4 в каком-то большом проекте.

И я знаю, что многие профессиональные программисты советуют полагаться на мои бизнес-классы вместо классов EF Model.

На самом деле в моем мозгу звучит звук "Дон"не зависит от этих сгенерированных классов! Просто пачкайте руки своими вещами, не позволяйте кому-то другому делать это за вас. !! "

Но на самом деле я не знаю, в чем проблемаиспользовать эти сгенерированные классы в таких больших «корпоративных» проектах.

Поэтому, пожалуйста, дайте мне понять, почему ???

Answer 1

Нет ничего плохого в использовании классов, сгенерированных EF. Вот для чего они здесь.

Но если вы неправильно примените технологию, у вас много проблем. Например, многие новички будут пытаться использовать эти сгенерированные EF классы для всего . Они возьмут классы, проведут их через границу AppDomain с помощью WCF или Remoting, и, возможно, они свяжутся с ними на своих интерфейсах. Это может сработать для быстрого и грязного приложения, основанного на CRUD, но оно не сработает ни с чем с реальным размером.

Почему бы и нет? Потому что сгенерированные EF классы моделируются в «домене» данных вашего приложения, а не в «домене» представления. То, с чем пользователь может захотеть взаимодействовать, часто не является объектом 1: 1 с таблицей в вашей базе данных. Например, пользователь может иметь сетку «Продукты». Внутри этой сетки будет указана общая сумма долларов, проданных за продукт, а также некоторые ориентировочные данные о продукте. Хотя ориентировочные данные (имя, размер и т. Д.), Вероятно, будут получены сразу из таблицы Product и, следовательно, сгенерированного класса Product из EF, агрегированные данные (общее количество проданных долларов) являются агрегированным значением.

Что мы обычно делаем, это используем в нашем сервисе сгенерированные EF классы, а затем используем сервис для преобразования классов EF в ViewModels, которые мы затем привязываем к нашим интерфейсам с помощью WPF (или любой другой вашей любимой технологии). Это дает нам разделение проблем, которые мы ищем.

Answer 2

Нужно быть особенно осторожным, когда подвергаешь классы, генерируемые EF, полностью Javascript.

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

Во-вторых, если вы также позволите MVC Model Binder десериализовать данные HTTP (либо через тело запроса, URL, либо любым другим способом) в EFмоделей, а затем сохранить его непосредственно в базе данных, вы находитесь на большой риск.Любой должен иметь возможность задавать HTTP-запросы на отправку вам объекта JSON, который будет перезаписывать поля, которые вы не ожидаете.Подумайте об этом объекте корзины покупок:

{cartItems: [{itemId:1, quantity:100, product:{ productId:23, price:0 }}]}

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

Answer 3

Если ваш проект большой, я рекомендую вам следовать разработке, управляемой доменом. Каждый класс домена состоит из нескольких компонентов: свойства сущности EF, внедрение свойств для поведения (форматирование данных, анализ, преобразование, копирование, проверка, конфигурация).

Если вы следуете принципу единой ответственности, у каждого класса должна быть только 1 ответственность. Классы модели EF должны быть предназначены для хранения данных и связи с инфраструктурой EF для генерации SQL времени выполнения. Другие классы позаботятся о форматировании, преобразовании, проверке и переносе.

Когда количество типов увеличивается, вам необходимо централизовать или упорядочить их, используя шаблон Фасад. Эти Фасады относятся к конкретным типам доменов. Таким образом, если вы начнете с генерации моделей EF, затем создадите вспомогательные типы (форматеры, валидаторы и т. Д.) И, наконец, создадите типы доменов, у вас не будет больше возможностей для совместной работы и распространения, чем вы могли бы получить, перейдя в обратную сторону. Сначала создайте типы вашего домена, создайте макеты и модульные тесты, а затем поделитесь им с вашими коллегами, чтобы позволить им связывать функции объекта домена с моделями EF. Вот как вы можете заниматься разработкой, управляемой доменом.

Answer 4

В дополнение к хорошему ответу Дейва я хочу упомянуть еще один важный недостаток использования сгенерированных классов: они являются производными от общего базового класса (EntityObject).Если у вас есть существующая модель домена с собственной иерархией наследования, это может быть проблемой, поскольку множественное наследование не поддерживается в .NET.