Entity framework reverse poco generator как пользоваться

Обновлено: 06.07.2024

Я использовал Entity Framework в Visual Studio 2012. Создайте модель сущности с помощью «сначала кода обратного инженера».

Но когда я только что установил Visual Studio 2015 и настроил электроинструменты EF от NuGet, я не могу найти опцию «Сначала проанализируй код».

Кто-нибудь знает, что я должен делать?

Entity Framework Power Tools - это Visual Studio расширение , поэтому вам необходимо сначала установить его. Но есть проблема, поддерживаемые версии Visual Studio 2010, 2012 и 2013. Visual Studio 2015 находится в предварительной версии. Я думаю, поэтому он еще не включен. Но у меня есть решение, которое работает для меня в таком случае.

В этом файле (это xml) вам нужно найти тег с именем SupportedProducts и добавить версию Visual Studio 2015 (перейдите к Help-> About Microsoft Visual Studio, чтобы проверить, какое издание вы установили).

Перезапишите файл extension.vsixmanifest в .vsix и попытайтесь установить его.

Надеюсь это поможет

Обновление 1

Я попытался с этой конфигурацией (Version: 14.0 и Edition: Ultimate), и это сработало. Чтобы сэкономить время, вы можете загрузить его в этом link . Я также добавил издание сообщества.

Обновление 2

Джули Лерман написала статью в своем блоге о том, как решить эту проблему.

Обновление 3

Я настоятельно рекомендую использовать EntityFramework Reverse POCO Generator при работе с устаревшими базами данных. Если ваша схема может меняться несколько раз без использования миграций, то предпочтительно иметь шаблон t4, который может помочь вам заново генерировать модель при каждом обновлении БД. Единственное, что вам нужно сделать, - это щелкнуть правой кнопкой мыши по вашему файлу .tt и выполнить параметр Run Custom Tool, и все. В EF Power Tools также есть опция, позволяющая настроить шаблон t4.

Я обновил EF Power Tools для работы с Visual Studio 2017 и сделал его доступным для загрузки из моего DropBox, если кому-то интересно:

Просто воспользуйтесь мастером edm и используйте «сначала код из базы данных», или, если вам не нравится код, основанный на атрибутах, используйте шаблон ef reverse poco

Database First без EDMX
Работа с отсоединенными графами
Модификация SQL. Добавление табличных указаний
Кэширование данных за пределами времени жизни DbContext
Retry при ошибках от SQL Server
Подменяем DbContext, изолируемся от реальной БД
Быстрая вставка

Database First без EDMX

Не хотелось бы начинать очередной раунд спора "Code First vs. Database First". Лучше просто расскажу, как облегчить себе жизнь, если вы предпочитаете Database First. Многие разработчики, использующие этот подход, отмечают неудобство работы с громоздким EDMX-файлом. Этот файл может превратить в ад командную разработку, сильно затрудняя слияние параллельных изменений вследствие постоянного "перемешивания" своей внутренней структуры. Среди прочих недостатков, для моделей с несколькими сотнями сущностей (обычный такой legacy-монолит), вы можете столкнуться с сильным падением скорости любого действия, работая со стандартным EDMX-дизайнером.

Решение кажется очевидным — необходимо отказаться от EDMX в пользу альтернативных средств генерации POCO и хранения метаданных. Задача-то несложная, и в EF есть "из коробки" — это пункт "Generate Code First From Database", доступный в Visual Studio (VS2015 точно). Но, на практике — очень неудобно накатывать изменения БД на полученную модель через этот инструмент. Далее, кто работает с EF достаточно давно — может помнить расширение Entity Framework Power Tools, решающее схожие задачи — но, увы, проект более не развивается (на VS2015 без хака не поставить), а часть разработчиков этого инструмента ныне работает непосредственно в команде EF.

Казалось бы, все плохо — и тут мы нашли EntityFramework Reverse POCO Generator. Это Т4-шаблон для генерации POCO на основе существующей БД с большим количеством настроек и открытым исходным кодом. Поддерживаются все основные фичи EDMX, и есть ряд дополнительных вкусностей: генерация FakeDbContext/FakeDbSet для юнит-тестирования, покрытие моделей атрибутами (напр. DataContract/DataMember) и др. Благодаря Т4, есть полный контроль за генерацией кода. Резюмируя: работает стабильно, команде нравится, легко мигрировать существующие проекты.

Работа с отсоединенными графами

Прикрепить к DbContext новый, либо ранее полученный в другом контексте единичный объект обычно не составляет труда. Проблемы начинаются в случае графов, т.е. сущностей со связями — EF "из коробки" не отслеживает изменения в содержимом navigation properties вновь присоединяемой к контексту сущности. Для отслеживания изменений, для каждого объекта-сущности во время жизни контекста должен существовать соответствующий entry — объект со служебной информацией, в том числе состоянием сущности (Added, Modified, Deleted и т.п.). Заполнить entries для присоединения графа — возможно как минимум 2 путями:

Хранить состояние в самих сущностях, самостоятельно отслеживая изменения. Таким образом, наш отсоединенный граф будет содержать в себе всю необходимую информацию для присоединения.
Ничего не делать заранее, а при добавлении графа в новый контекст — подтянуть из БД исходный граф и проставить состояния entry на основании сравнения двух графов.

Тем или иным способом, необходимо обеспечить актуальность значений State, чтобы после ручного присоединения каждой сущности в графе к контексту:

пройти по всем entry, редактируя их состояние:

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

вызов сей — добавит в контекст сущность root, обновив при этом navigation property с коллекцией дочерних объектов Childs, ценой SELECT-а к БД одного лишь. Что стало возможным благодаря библиотеке GraphDiff, автор которой сделал всю черную работу и выловил основные баги.

Модификация SQL. Добавление табличных указаний

Генерация, казалось бы, простой инструкции SELECT… FROM Table WITH (UPDLOCK) не поддерживается EF. Зато есть interceptor'ы, позволяющие модифицировать генерируемый SQL любым подходящим способом, например, с помощью регулярных выражений. Давайте добавим UPDLOCK на каждый генерируемый SELECT в пределах времени жизни контекста (естественно, гранулярность — не обязательно контекст, всё зависит от вашей реализации):

Для этого, объявим метод With внутри контекста и зарегистрируем interceptor:

Список изменений в версии 4.1 можно найти в статье - What's New (Entity Framework 4.1), занимательно, что существует также статья - What's Not Supported (Entity Framework 4.1)

Итак, вариант 1 - Entity Framework Power Tools

Конектимся к базе:

Reverse engineering нагенерит нам POCO сущностей по базе и служебные классы маппингов.

POCO классы вида:

Как видим в них ничего лишнего, разве что наличие Nullable или виртуальных свойств может выдать такой класс. Связанные таблицы реализуются как виртуальные свойства типа ICollection. Тем не менее это чистые объекты без лишних зависимостй

В принципе с эти можно жить имея класс контекст. Но нам этого мало. Хочется иметь для этого нормальный Data access layer. А для гурманов хочется такой слой с использованием паттернов Repositorу, UnitOfWork. Чтобы не делать много рутиной работы будем использовать T4 Template.

Запустим его. Получи базовые классы и реализации показанные ниже:

Базовая конкретная реализация интерфейса IRepository от этой реализации можно наследовать свои более конкретные репозитории:

Конкретная реализация интерфейса IUnitOfWork:

Далее код показывать не буду так как в принципе по интерфейсам и базовым классам можно понять о чем речь. Остальной пример уровня доступа к данным в приложении по ссылке в конце.

Покажу еще код использования такого слоя доступа к данным:

А дальше можем к примеру заиспользовать Т4 скрипт из первого способа.

Хотя лично для меня первый вариант, который я описал предпочтительнее

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

Ранее я использовал EF Power Tools, который включал опцию ReverseEngineerCodeFirst, а в процессе переключения на EntityFramework обратный генератор POCO.

Используя генератор POCO, я теперь получаю ошибку в строке .Include(. ) :

'Система.Данные.Сущность.IDbSet' не содержит определения для 'Включить', а не метод расширения 'включить', принимающий первый аргумент типа - Система.Данные.Сущность.IDbSet ' может быть найден (вы отсутствует директива using или ссылка на сборку?)

В созданном контексте (и IContext):

В шаблоне context tt я изменил экземпляры IDbSet на DbSet , что исправило проблему, но мне любопытно, почему, если IDbSet является интерфейсом для DbSet , Почему IDbSet не работает?

Ошибка говорит все:

Система.Данные.Сущность.IDbSet" не содержит определения для "Include" и никакого метода расширения.

Интерфейс просто не имеет метода. Я не уверен, почему эти методы не являются частью интерфейса. Может быть, потому, что IDbSet был введен для облегчения насмешек, а Include - это метод, который очень трудно высмеять.

Вместо этого вы можете использовать один из Include методы расширения в пространстве имен System.Data.Entity . Эти методы определяются на IQueryable(<T>) , который является интерфейсом, реализующим IDbSet .

То же самое верно и для другого важного метода, которого нет в интерфейсе IDbSet : AsNoTracking. (Также трудно издеваться - в каком - то смысле-потому что отслеживание трудно издеваться).

Я думаю, что, возможно, вы просто пропускаете утверждение using System.Data.Entity; .

Я решил точно такую же проблему, переустановив Entity Framework.
Проблема заключалась в отсутствии ссылки на EntityFramework.файл DLL.

IDbSet-это устаревший интерфейс Microsoft. Генератор не может быть в dbset.

Обновление до последнего генератора EF Reverse POCO здесь .

Исходный код здесь.

Ранее я использовал электроинструменты EF , которые включали опцию ReverseEngineerCodeFirst ,и в процессе переключения на EntityFramework обратный генератор POCO.

При использовании генератора POCO я теперь получаю ошибку в строке .Include(. ) :

'System.Data.Entity.IDbSet' не содержит определения для 'Include' и ни один метод расширения 'Include', принимающий первый аргумент типа 'System.Data.Entity.IDbSet' , не может быть найден ( отсутствует ли директива using или ссылка assembly?)

В сгенерированном контексте (и IContext):

В шаблоне context tt я изменил экземпляры IDbSet на DbSet , что исправило проблему, но мне любопытно , почему, если IDbSet -это интерфейс для DbSet , то почему IDbSet не работает?

4 ответа

Я использую сгенерированные классы POCO и Entity Framework. Чтобы сделать код менее сложным, я пытаюсь удалить все навигационные свойства из кода, сохраняя при этом ограничения внешнего ключа в базе данных (навигационные свойства приносят нам больше вреда, чем пользы). Если я удалю их вручную из.

У меня есть проблема, которую, как я считаю, можно решить простым пониманием. Я использую Entity Framework 5 с кодом first и POCO. У меня есть все навигационные свойства, правильно настроенные (виртуальные) для всех моих объектов POCO. Проблема возникает, когда я запрашиваю объект (POCO), а затем.

Я думаю, что, возможно, вы просто пропускаете утверждение using System.Data.Entity; .

IDbSet-это устаревший интерфейс Microsoft. Вместо этого генератор теперь использует DbSet.

Обновите последнюю версию генератора EF Reverse POCO здесь .

Исходный код находится здесь .

Я решил точно такую же проблему, переустановив Entity Framework.

Проблема заключалась в отсутствующей ссылке на EntityFramework.dll.

Ошибка говорит сама за себя:

System.Data.Entity.IDbSet' не содержит определения для 'Include' и не содержит метода расширения.

В интерфейсе просто нет метода. Я не уверен, почему эти методы не являются частью интерфейса. Возможно, потому, что IDbSet был введен для облегчения насмешек, а Include -это метод, который очень трудно высмеять.

Вместо этого вы можете использовать один из Include extension methods в пространстве имен System.Data.Entity . Эти методы определены в IQueryable(<T>) , который является интерфейсом, реализуемым IDbSet .

То же самое верно и для другого важного метода, которого нет в интерфейсе IDbSet : AsNoTracking . (Также трудно издеваться - в некотором смысле - потому что отслеживание трудно издеваться).