TDD и ADO.NET Entity Framework

В последнее время я играю с ADO.NET Entity Framework, и я считаю, что это соответствует моим потребностям в проекте, который я разрабатываю. Я также считаю прохладным его неинвазивный характер.

После создания модели данных из существующей базы данных вы столкнулись с задачей интеграции сгенерированной модели и вашей бизнес-логики. Более конкретно, я привык к интеграции - тестируйте свои классы, которые взаимодействуют с хранилищем данных через mocks/stubs интерфейсов DAL. Проблема в том, что вы не можете сделать это, используя ADO.NET Entity Framework, потому что созданные им объекты - это простые классы без интерфейса.

Возникает вопрос: как применить подход TDD к разработке приложения, использующего ADO.NET Entity Framework? Возможно ли это, или я должен перейти на другой набор инструментов DAL-генерации?

Ответ 1

Одна из серьезных критических замечаний против Entity Framework заключалась в том, что ее трудно проверить, например, в ALT.Net Голосование об отсутствии уверенности, указанный в gef.

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

Если тестируемость является большой проблемой, вам может потребоваться рассмотреть другую структуру ORM, такую как NHibernate, по крайней мере, до тех пор, пока не выпустят Entity Framework 2.0.

Ответ 2

Хотя на исходный вопрос был дан ответ, я чувствую, что могу что-то добавить:

В настоящее время я использую Entity Framework 4.0 на интранет-сайте, который я создаю. Я могу проверить все в своей бизнес-логике и контроллерах без подключения к базе данных с помощью поддержки POCO, которая была добавлена.

Хотя POCO может быть сгенерирован из нового шаблона t4, включенного в VS 2010, то, что я не смог найти в VS 2010, является t4-шаблоном для создания вашего контекста объекта (контекст объекта в основном работает как встроенный блок работы для EF и необходим для сопоставления ваших объектов EF с POCOs). К счастью, Joachim Lykke Andersen в своем блоге Entity Framework 4.0 Beta 1 - POCO, ObjectSet, Repository и UnitOfWork написал t4 для его создания, и это было очень полезно. Если вы используете решение с использованием EF4, которое можно тестировать без подключения к базе данных, я настоятельно рекомендую реализовать что-то похожее на его решение, которое включает в себя общий репозиторий, единицу рабочей обертки и единицу работы factory. Это было очень полезно.

Удачи.

Ответ 3

Я согласен с тем, что версия 1 Entity Framework является преступлением против дизайна, и это определенно получило мой голос без доверия. Я отношусь к группе продуктов EF, хотя для подтверждения отказа и ответа, открывая процесс проектирования для сообщества. Следующий выпуск не будет идеальным, он может быть даже не готов для использования в приложении уровня производства, но я думаю, что они наконец начинают понимать, что важно для тех, кто знает, что плохой дизайн - это плохой бизнес. Это было сказано... Я все еще подозрительно. Непрерывная обратная связь с дизайном является новой для этих ребят, и я прочитал довольно много заявлений в блоге ADO.NET, которые поднимают яркие красные флаги. Мы увидим, как это происходит с выпуском .NET 4.0.

Кажется, что они пытаются:

Прохождение разработки с использованием платформы Entity Framework 4.0

Ответ 4

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

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

У команды есть способность эволюционировать дизайн и инкрементная доставка поврежденные инфраструктурой Entity невнимание к основному программному обеспечению принципы проектирования, такие как разделение Обеспокоенность".

Блаженно украденный отсюда: http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

Ответ 5

Если вы посмотрите на инструменты генерации DAL, вам будет сложно интегрировать это с TDD. Большинство инструментов генерации dal, которые я знаю, также генерируют ваши бизнес-объекты и плотно связывают их с DAL-тестированием.

Вы можете посмотреть на инструменты OR-mapping, такие как nHibernate и, возможно, Linq на sql, которые позволяют "незнание стойкости", вы можете сами определить свои бизнес-объекты и не иметь ссылок на DAL или любой другой код инфраструктуры. Это значительно упрощает тестирование вашей бизнес-логики из вашей базы данных. Я нашел, что это также позволяет гораздо лучше использовать другой сценарий, например, случайно подключенных клиентов.

Ответ 6

Этот ответ изменился на "Да, вы можете".

Вы можете создавать POCO и интерфейсы с помощью настраиваемых шаблонов T4, таких как https://entityinterfacegenerator.codeplex.com/, а затем создавать насмешливые объекты для проверки входа и выхода EF без удара базы данных.