Почему EF Entities делают зависимость и необходимость POCO

Question

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

Я планировал использовать шаблон Repository для взаимодействия с данными.Объекты, которые я собирался вернуть из репозиториев, должны были быть объектами, собранными из Linq для контекста данных сущностей (EF4).

Я читаю в «Внедрение зависимостей» изМарк Симан, который делает это, создает важную зависимость и определенно усложнит тестирование (именно это он использует объекты POCO в библиотечном проекте).

Я не понимаю, почему.Хотя объекты создаются с помощью контекста linq to entity, я могу создать их, просто вызвав конструктор, поскольку они были обычными объектами.Поэтому я предполагаю, что возможно создать поддельные репозитории, которые разбивают эти объекты на вызывающую сторону.

Меня также беспокоит автоматическое создание классов POCO, что не очень просто.

Можеткто-нибудь принести свет?Являются ли объекты POCO необходимыми для развязанного и тестируемого проекта?

** РЕДАКТИРОВАТЬ: Благодаря Yuck я понимаю, что лучше избегать автогенерации с шаблонами, что приводит меня к вопросу дизайна.Если я пришел из большой унаследованной базы данных, в которой его таблицы предполагают различные виды ответственности (не вписывается в концепцию класса с одной ответственностью), как лучше всего справиться с этим?

Удалить базу данных не вариант; -)

Answer 1

Нет, они не нужны, это просто делает вещи проще, чище.

Библиотека POCO не будет знать, что она используется Entity Framework. Это позволяет использовать его другими способами - например, вместо модели представления. Это также позволяет использовать один и тот же проект с обеих сторон службы WCF, что устраняет необходимость создания объектов передачи данных (DTO).

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

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

Answer 2

Я планировал использовать шаблон Repository для передачи данных.Объекты, которые я собирался вернуть из репозиториев, должны были быть объектами, собранными из контекста данных Linq to entity (EF4).

Классы по умолчанию (не POCO), которые генерирует EF, содержат прокси дляЛенивая загрузка и привязана в бедро к Entity Framework.Это означает, что любой другой класс, который хочет использовать эти классы, должен будет ссылаться на требуемые сборки EF.

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

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