Comments 47
Опять же, рефлексия для того и создана чтобы получать информацию о типе.
Я рад что кто-то сможет построить и запустить какой-нибудь DbContext с единственным конструктором, принимающем ICustomConfigurationService. И выполнить в нем методы, неизвестные большинству (GetTables или аналоги).
И все равно остаться без необходимых атрибутов полей.
Но это, увы - обходной путь.
- Может проще было изобразить наборы классов через Class Diagram?
Все равно кода нет. - "Типичный вывод набора данных в опрятном дизайне" — коллаж взрывает мозг. :)
- Это у меня глюк браузера, или cut DbSetParser.cs не открывается?
Установил Class Diagram - не работает. ReSharper-а нет под рукой. Да и большинство подобных публикаций и не имеет диаграмм классов. Зависимости сверху вниз слева направо. (слева направо использует\состоит из, сверху вниз - набор эквивалентных классов)
Как и CRUD на пять таблиц в виде тестового :) Поверьте "text tables with Create Update Delete labels" выглядит еще хуже
Поправил
Для чего рефлексия? Почему не подошёл EF? На что драматически влияет глубина связей? Какая задача решена в данной статье?
Для чего рефлексия? Почему не подошёл EF?
EF вообще не подходит для этих целей. Вы собираетесь потом в Fody искать строки подключения? :D
Первые 2 ссылки с гугла:
https://stackoverflow.com/questions/3892926/entity-framework-get-list-of-tables
Даже для простого получения списка таблиц нужно создать контекст БД, подключится.
Не говоря уже об атрибутах полей данных.
На что драматически влияет глубина связей?
Не знаю, но даже у крайне примитивных инструментов вроде EasyData почему-то находятся толпы поклонников.
На объём работы же. Если вам Нравится протягивать поля руками и писать по 100 форм (а потом и отлаживать это все) в качестве тестового задания - делайте, кто Вам не дает.
Какая задача решена в данной статье?
Вот так, за час-два мы получили через рефлексию почти исчерпывающую информацию о таблицах в нашей БД, их полях, атрибутах полей, связях и всем остальном.
*В Fody искать возможные инициализации параметров конструктов DbContext для 100 и 1 случая (разные контейнеры, разные проекты) ? )
И вытаскивать из них строки подключения? )
В EF Core создать контекст можно полустандартным способом через IDesignTimeDbContextFactory (его использует утилита dotnet ef).
Подключаться к БД создание контекста не требует.
В EF Core создать контекст можно полустандартным способом через IDesignTimeDbContextFactory
Отличный интерфейс.
А где список таблиц, полей и ссылок? )
И единственный метод:
Creates a new instance of a derived context.
А что ещё надо-то? Создаёте контекст, из него достаёте модель, в модели есть вся нужная информация
Выше написано - DbContext и производные не позволяют получить даже список таблиц.
И напишите как вы атрибуты asp net будете вытаскивать из DbContext без рефлексии.
Выше — это где?
Всё там в модели есть.
Кстати, откуда взялось требование "без рефлексии"? Если что, даже asp.net эту самую рефлексию для своих атрибутов использует...
Вы и написали про рефлексию:
В EF Core создать контекст можно полустандартным способом через IDesignTimeDbContextFactory
Зачем? Для чего? если всю информацию можно получить из типа? (без создания экземпляра). Тем более в Fody проще получить все типы из сборки, и уже работать с типами. А не искать какие-то фабрики которые вроде могут создавать экземпляры DbContext без параметров.
Всё там в модели есть.
Ничего нет, там тип, из которого нужно вытаскивать свойства, атрибуты, получать их типы, получать ссылки public virtual AnotherItems и т.д.
Кроме того, на этапе выявления А это ссылка на таблицу или что тут? (потому что virtual тяжело определить, если вообще возможно) Вас ждет очередной сюрприз.
Сюрпризы ждут как раз вас, потому что имя таблицы может быть задано следующими способами:
- На основе имени класса с использованием плюрализации
- На основе имени класса с пользовательской конвенцией именования
- Атрибутом, "навешанным" на класс
- Через model builder напрямую
- (Для EF model first) указаны в storage model
Удачи воспроизвести всё средствами Fody.
Если вам нужны именно имена таблиц так как их видит EF / EF Core — единственным надёжным способом их получить является "заглянуть в модель".
Ничего нет, там тип, из которого нужно вытаскивать свойства, атрибуты, получать их типы, получать ссылки public virtual AnotherItems и т.д.
Не понимаю о каком public virtual AnotherItems идёт речь, не вижу ничего похожего в интерфейсе IEntityType
Кстати, имя таблицы можно вытащить через метод RelationalEntityTypeExtensions.GetTableName
Сюрпризы ждут как раз вас, потому что имя таблицы может быть задано следующими способами:
При чем тут имя таблицы? Я работаю с классом DbContext и DbSet<> и читать еще и все атрибуты EntityFramework (помимо asp.net) мне не нужно и я не буду.
Не понимаю о каком public virtual AnotherItems идёт речь, не вижу ничего похожего в интерфейсе IEntityType
Мне не нужно сопоставлять модель БД и DbContext. Я думал это ясно из названия статьи.
Здорово, перечислите мне методы этих интерфейсов IEntityType и прочих, которые позволят получить все таблицы, поля, и атрибуты полей.
Типичным случаем, показанным в примерах Code First, является наличие DbContext с открытыми автоматическими свойствами DbSet для типов сущностей модели.
Остальные способы описания таблиц (если они есть) больше похоже на попытку OpenSource сообщества размазать данные по проекту и оставить как попало. Вот есть контекст, у него есть таблицы. Готовый удобный объект с таблицами.
При чем тут имя таблицы?
При том, что вы во всех комментариях пишете тут именно про таблицы, а не про сущности. Вот мне и показалось что вам нужны именно они.
Здорово, перечислите мне методы этих интерфейсов IEntityType и прочих, которые позволят получить все таблицы, поля, и атрибуты полей.
А может, всё-таки погуляете по ссылкам в документации?
Остальные способы описания таблиц (если они есть) больше похоже на попытку OpenSource сообщества размазать данные по проекту и оставить как попало. Вот есть контекст, у него есть таблицы. Готовый удобный объект с таблицами.
Если вам удобен всего 1 вариант — это не означает что он удобен для всех.
Если вам удобен всего 1 вариант — это не означает что он удобен для всех
Конечно, репозиторий BrainFuck-а довольно популярен. Однако даже при поддержке всякие чудеса вроде "Ой, а классы унаследованные от Control не надо регистрировать в контейнерах" - да, если это asp net, это может быть терпимо. Если у вас в Бэкенде на добрую сотню-две тысяч строк таблицы(!) можно добавлять из нескольких точек(настолько часто меняется схема данных?!) - это уже не отлаживается и не поддерживается.
Потому что найти все ссылки на вызов метода и найти 10 вариантов реализации одной и той же функциональности - это разница в 10 раз по времени.
Не говоря уже о том, что если эти практики попадут в OpenSource и будет поддержка со стороны IDE - тогда может еще терпимо. Но если это Ваш код, который не фиксирует точки функциональности - это конец проекта.
А может, всё-таки погуляете по ссылкам в документации?
Погуглил, не нашел методов GetTables, GetLinks и подобных. И написал аж 200 строк кода :)
При том, что вы во всех комментариях пишете тут именно про таблицы, а не про сущности. Вот мне и показалось что вам нужны именно они.
Да нет, мне нужны таблицы из контекста и описание моделей данных(сущности). А так же вся необходимая информация из сущностей.
Если у вас в Бэкенде на добрую сотню-две тысяч строк таблицы(!) можно добавлять из нескольких точек(настолько часто меняется схема данных?!) — это уже не отлаживается и не поддерживается.
Нет, там другое бывает. К примеру, работа с унаследованной БД, или совместная работа с БД несколькими инструментами. Или просто на проекте есть DBA.
Кстати, вы же в курсе про существование класса IdentityDbContext, который может быть использован как базовый и содержит внутри уже готовый набор таблиц?
Погуглил, не нашел методов GetTables, GetLinks и подобных.
Почему я нашёл их сразу же?
А где реализации упомянутого IDesignTimeDbContextFactory?
You can also tell the tools how to create your DbContext by implementing the Microsoft.EntityFrameworkCore.Design.IDesignTimeDbContextFactory<TContext> interface: If a class implementing this interface is found in either the same project as the derived
DbContextor in the application's startup project, the tools bypass the other ways of creating the DbContext and use the design-time factory instead.
Ок, то есть мне надо еще сконструировать этот самый DbContext. (который я скорее всего потяну как зависимость откуда-то, учитывая сказанное вами).
Без ConnectionString или как-то еще.
И не прострелить себе ногу вызывая эти методы?
Тем более опять появилась сущность которая работает без каких-либо связей в коде, что является плохой практикой.
Кстати, вы же в курсе про существование класса
IdentityDbContext, который может быть использован как базовый и содержит внутри уже готовый набор таблиц?
Нет, равно как я еще не в курсе относительно оставшихся 10 тысяч классов внутри библиотеки .net.
И тем более деталей реализации. (Потребуется ли подключение к БД или нет?).
Поэтому я выбрал надежный способ - получить все через рефлексию. И получил. Тем более без потраченных 30 минут тяжело сказать (да и в документации это не описано) когда потребуется ConnectionString.
И это - основы ООП. Если что то принимается в конструкторе, это что-то из конструктора может использоваться.
Реализацию IDesignTimeDbContextFactory должен написать тот, кто пишет контекст.
Ок, то есть мне надо еще сконструировать этот самый DbContext. (который я скорее всего потяну как зависимость откуда-то, учитывая сказанное вами).
Нет, не вам. И нет, контекст через IDesignTimeDbContextFactory должен создаваться без лишних зависимостей, слова "DesignTime" в названии интерфейса не просто так.
Нет, равно как я еще не в курсе относительно оставшихся 10 тысяч классов внутри библиотеки .net.
А зря, кругозор лишним не бывает, особенно когда вы берётесь делать громкие заявления относительно того как другие должны писать их код.
И особенно в отношении стандартных частей приложения, которые берутся просто по умолчанию в любом туториале (а ASP.NET Core Identity — одна из таких частей).
И тем более деталей реализации. (Потребуется ли подключение к БД или нет?).
Нет, не потребуется. Я вам уже несколько раз это написал.
А зря, кругозор лишним не бывает, особенно когда вы берётесь делать громкие заявления относительно того как другие должны писать их код.
Увы, на среднюю сертификацию разработчика на .net надо знать гораздо меньше.
Все классы (и их поведение) узнать невозможно.
Плюс фабрика крайне неудобна. (и как выяснилось еще и специфична). Я прочел более 4-х толстенных книг по шарпу и ни разу не слышал про данный интерфейс.
Тем более появляется новое требование
Реализацию IDesignTimeDbContextFactory должен написать тот, кто пишет контекст.
Увы, скорее всего большинство DbContext_ов на проекте будет либо уже без IDesignTimeDbContextFactory, либо без конструкторов без аргументов, либо никто даже не будет реализовывать подобный интерфейс.
Увы, на среднюю сертификацию разработчика на .net надо знать гораздо меньше.
Любая сертификация разработчика — хрень. Там всегда нужно знать меньше чем нужно для реальной работы.
Плюс фабрика крайне неудобна. (и как выяснилось еще и специфична).
Фабрика крайне удобна. Она позволяет не гадать какой такой магией инструмент получает экземпляр контекста, а напрямую передать ему нужный.
Увы, скорее всего большинство DbContext_ов на проекте будет либо уже без IDesignTimeDbContextFactory, либо без конструкторов без аргументов, либо никто даже не будет реализовывать подобный интерфейс.
Так это же просто решается. Пишете в документации: для использования инструмента требуется реализовать IDesignTimeDbContextFactory, и даёте ссылку на документацию. Ещё можно дать пример реализации. Всё.
Пишете в документации: для использования инструмента требуется реализовать IDesignTimeDbContextFactory
Очень просто, давно писали конфиги для CCleaner? )
Это нарушает цепочку зависимостей - объекты зависят от инструментов и утилит, а не наоборот.
Тем более надо всего-лишь написать 200 строк кода, и не смотреть на "пользовательские реализации интерфейса для создания экземпляров DbContext".
Любая сертификация разработчика — хрень. Там всегда нужно знать меньше чем нужно для реальной работы
Ну да, конечно )
Очень просто, давно писали конфиги для CCleaner? )
А при чём тут вообще CCleaner?
Это нарушает цепочку зависимостей — объекты зависят от инструментов и утилит, а не наоборот.
Не вижу нарушения.
А при чём тут вообще CCleaner?
При том, у вас в общем-то ваша рисовалка CRUD вообще не должна предъявлять никаких дополнительных требований к источникам данных?
Прямая аналогия - напишите свою конфигурацию для CCleaner.
Не вижу нарушения.
Ядро системы и разработка ядра системы (слоя с данным и бизнес логики) начинает зависеть от написания сервисов со странным интерфейсом для работы вашей утилиты.
Замечательная архитектура.
И вы мне пытаетесь это доказать на протяжении 20 сообщений.
Ваше "ядро" уже зачем-то зависит от EF, хотя это такой же инструмент.
А ещё ваш инструмент прямо сейчас предписывает ядру иметь строго определённую структуру, но почему-то зависимостью вы это не считаете.
EF вообще не подходит для этих целей. Вы собираетесь потом в Fody искать строки подключения? :D
EF может сгенерировать все классы по существующей модели БД.
При чём тут строка подключения? Она в конфиге задаётся как и всегда.
Даже для простого получения списка таблиц нужно создать контекст БД, подключится.
Это вообще непонятно, зачем получать список таблиц. Или вы хотите сделать менеджер БД? Зачем? Есть же DBeaver, DataGrip и куча других инструментов для этого :)
Или задача так и звучала? Нужно приложение, которое может CRUD любой БД? Сама по себе задача не имеет практического смысла. А как для задания для собеседования, выглядит максимально странной.
На объём работы же. Если вам Нравится протягивать поля руками и писать по 100 форм (а потом и отлаживать это все) в качестве тестового задания - делайте, кто Вам не дает.
Всё ещё не понимаю. А что делать с деревьями? Там же глубина практически бесконечная. Глубина связей 1, 2 или 100500 вообще не должна ни на что влиять. Ну может только если вы таким образом модель построили, что это драматически начало как-то усложнять работу, но это проблема модели, а не глубины связей.
Вот так, за час-два мы получили через рефлексию почти исчерпывающую информацию о таблицах в нашей БД, их полях, атрибутах полей, связях и всем остальном.
Прошу не принимать на свой лично счёт, я не придираюсь :) Но выглядит это как в древней картинке "Вот так с помощью нехитрых приспособлений буханка белого хлеба превратилась в троллейбус".
Какую практическую задачу это решает? для чего это?
Сама по себе задача не имеет практического смысла.
Ого, лепить тысячи форм CRUD для миллионов таблиц никому не нужно? А как же 1С?
Это вообще непонятно, зачем получать список таблиц
Делать CRUD без таблиц?
Всё ещё не понимаю. А что делать с деревьями?
А я откуда знаю, это уже уровень Отображения. Скорее всего я не буду лепить какие-нибудь CompositeIndex-ы для глубины блуждания по дереву в 100 :). Придется написать немного на JavaScript. Ну и для глубины в 100500 видимо придется как-то передавать структуру индексов.
Прошу не принимать на свой лично счёт, я не придираюсь :) Но выглядит это как в древней картинке "Вот так с помощью нехитрых приспособлений буханка белого хлеба превратилась в троллейбус".
Так в заголовке все написано, я делаю свой генератор CRUD. Часть 1 - получаем данные о таблицах и их данных.
Нравится часами-днями рисовать банальные CRUD-ы - пожалуйста. Благо большинство задач из Веб-а именно из этого разряда - нам нужны формочки смотреть\редактировать вот это.
И почему-то задач "Переписать алгоритмы на ilgpu" нет нигде ).
Ого, лепить тысячи форм CRUD для миллионов таблиц никому не нужно? А как же 1С?
Не имеет значения 1 там таблица или миллион. БД это не эксель, редакторов БД вагон. Не существует такой бизнес-задачи, чтобы тупо создавать, удалять или редактировать как есть записи в табличках. За этим стоит довольно сложная бизнес-логика. А для реализации бизнес-логики нужны типизированные объекты, но не какие-то рандомные нетипизированные таблички.
1С это не редактор таблиц в БД. Там сложная бизнес-логика. Именно она представляет ценность, 1С упрощает работу с данными и обеспечивает в несколько слоёв контроль доступа, бизнес-целостности, аудит и т.д. и т.п.
У вас ничего этого нет. Достали таблички и прикрутили возможность создать, удалить или отредактировать запись. Кому и зачем вообще такое нужно в принципе? Особенно если эта задача уже решена более продвинутыми средствами, коих вагон.
А я откуда знаю, это уже уровень Отображения. Скорее всего я не буду лепить какие-нибудь CompositeIndex-ы для глубины блуждания по дереву в 100 :). Придется написать немного на JavaScript. Ну и для глубины в 100500 видимо придется как-то передавать структуру индексов.
Какая практическая ценность-то? :) Ну вот вы редактируете данные и связи. Какую бизнес-задачу это решает-то?
Нравится часами-днями рисовать банальные CRUD-ы - пожалуйста. Благо большинство задач из Веб-а именно из этого разряда - нам нужны формочки смотреть\редактировать вот это.
Ну давайте копнём глубже. Вы накидали за 2 часа условно супер-универсальный CRUD. Подойдём основательно и выделим больше времени. Допустим 2 недели. Сделали CRUD, теперь можно редактировать любые таблички, вносить данные. Что дальше? :) Можно разогнать табун разработчиков. Теперь можно вводить любые данные. Программа готова на века :)
Я ж спрашиваю какую практическую задачу бизнеса это решает. А не задачу разработчика. Формочки сами по себе никому не нужны, за ними большой слой логики. Чтобы реализовать эту логику, нужны конкретные типы данных, чтобы получились объекты, которые можно считывать и сохранять, при чём не тупо все 100500 полей загнать в БД. Вообще не припомню такой задачи за всю жизнь, когда нужен был тупой CRUD. Что с этим делать-то потом? :)
Какая практическая ценность-то? :)
Давайте по пунктам - CRUD есть везде.
Начиная от примитивных текстовых форумов заканчивая подписками на сервис ChatGPT - все строится на списках, элементах, связанных списках, которые хранятся в базе данных.
Формочки сами по себе никому не нужны, за ними большой слой логики.
Ага, и логика эта - или валидация, или события (и их обработчики). Вот это поворот. Или отдельные микросервисы.
Ну давайте копнём глубже. Вы накидали за 2 часа условно супер-универсальный CRUD. Подойдём основательно и выделим больше времени. Допустим 2 недели. Сделали CRUD, теперь можно редактировать любые таблички, вносить данные. Что дальше? :) Можно разогнать табун разработчиков. Теперь можно вводить любые данные. Программа готова на века :)
Все, добавляю IdentityServer и раздаю права. Делаю описания таблиц и прав на json. Назовите мне что я не смогу сделать :). (или значительно ускорить разработку, как и наивно полагали инженеры Microsoft, когда делали свой генератор CRUD)
Похоже в Microsoft-то дураки набитые сидят, и делают генераторы формочек :)
Это если не вдаваться в теорию. Что для одинаковых сущностей достаточно написать код 1 раз, чтобы обработать бесконечное множество сущностей.
А сущности это абстракции на основе реальный объектов имеющие общие свойства, параметры, и прочее, выведенный статистически.
То же самое с комбинациями сущностей.
И вот, мы создаем язык lisp.
А чтобы добавлять или просматривать эти самые сущности, нам нужен CRUD, желательно работающий со ссылками на другие таблицы.
И статьи на хабре, и связанные 1 to N комментарии - тоже лежат в области генерации формочек.
Понятие CRUD это понятие БД. Т.е. операции INSERT (C=CREATE), SELECT (R=READ), UPDATE (U), DELETE (D). Когда говорят о CRUD в бизнес-логике, это НЕ тоже самое, что операции в БД, оно похоже, и для удобства применяется этот термин.
Чаще всего DELETE в бизнесе это вообще UPDATE+INSERT в БД. Иногда UPDATE, это на самом деле INSERT. А CREATE это INSERT+UPDATE. И бог знает ещё что.
И чем сложнее бизнес-логика, тем большее количество операций оно сопровождает, и порой даже не в одной БД, а в нескольких.
Какой смысл в тупом CRUD-е один к одному? Зачем это нужно бизнесу?
Давайте с другой стороны посмотрим. Где все эти CRUD-генераторы, повально захватившие мир? На которых написаны все системы? И толпы уволенных программистов, так как теперь особо программировать нечего, теперь всё генерируется?
Похоже в Microsoft-то дураки набитые сидят, и делают генераторы формочек :)
Нет ничего плохого в генерации, более того, всё что может сделать машина, вместо человека, нужно поручить машине. Но ваш CRUD-генератор, это работа, которая не имеет практической ценности.
Давайте в бизнес посмотрим. Какие задачи это решает? Можно ли интернет-магазин сделать за 2 часа? Бухгалтерскую систему? Складской учёт? Да хоть бы тупейший TODO-менеджер?
Где у вас строго типизированные модели, на которых можно легко пилить логику, используя строгую типизацию?
Бизнес и люди работают с сущностями из таблиц.
Вы - сторонник написания всего руками?
Давайте в бизнес посмотрим. Какие задачи это решает? Можно ли интернет-магазин сделать за 2 часа? Бухгалтерскую систему? Складской учёт? Да хоть бы тупейший TODO-менеджер?
Как ни странно.
Бизнес и люди работают с сущностями из таблиц.
"Бизнес и люди" работают с сущностями из доменной модели. Эти сущности часто (но не всегда) мапятся на таблицы, и иногда (но не очень часто) соотносятся с этими таблицами один к одному. Чем сложнее бизнес, тем дальше домен будет от таблиц.
Универсальные CRUD очень соблазнительны для программиста (я как минимум два написал сам, и еще один поддерживал долгое время), но очень быстро начинают проигрывать в пользовательском опыте.
А на python-е тоже дураки пишут?
Народ говорит там уже генераторы CRUD на уровне средней админки.
Админка это не целевая задача, а сопровождающая. Да и там CRUD генерируется как код, как бойлерплейт, который потом дальше уже развивается и наращивается руками. Да, очевидно, если у нас есть 10 справочников в админке, и по сути там почти нет другой логики, кроме как добавить, изменить или удалить запись. Но это только в тупой и очень простой системе. Далее оказывается, что нельзя просто изменить запись. Или требуется распространять изменения через поток событий.
Формочки генерировать на основе мета-модели это одно. А завязываться на модель БД динамически, это уже совсем другое. Это практически расстрел ног из всех стволов.
typeof(DbSet<object>).GetGenericTypeDefinition()тут компилятор, к счастью, умеет так:
typeof(DbSet<>)Для тех, кому лень читать весь срач -
Один предложил добавить реализацию интерфейса IDesignTimeDbContextFactory к каждому экземпляру DbContext, чтобы строить экземпляр DbContext. (И вытаскивать данные о таблицах и прочем)
Второй считает что CRUD, списки и формочки бизнесу не нужны. Видимо существует другой, особый подход, основанный не на объектах и их списках.
Читал комментарии, читал и не выдержал.
Но все же, есть пара моментов что хочу заметить:
1)Способов описания модели БД у EF действительно несколько, я например не люблю атрибутами описывать модели, мне проще структуру видеть в одном месте.
2)Поддержка OwnedEntity, ManyToMany.
3)DbContext-у, для чтения модели из него, не нужно подключение к БД на самом деле.(если вы сами не сделали это)
4)С валидацией не всегда все просто, у меня например в проекте есть поле, для проверки которого нужно делать запрос к БД, то есть просто регуляркой не пройдешься.
В целом, если решение вам помогает и подходит под ваши требования, почему бы и нет.
Единственное, замечу, не пытайтесь выставлять свое мнение как единственное верное:
1)Например про атрибуты в модели, то что вам так нравится не значит что так должны делать все, понятное дело что в вашем инструменте будут преобладать ваши вкусы, но не проецируйте их на других.
2)проекты разные бывают, есть много ситуаций где простейшее решение не очень подходит.
У меня в проекте есть таблица созданная по сути ради оптимизации БД, чтоб разделить большую сущность, но при этом по факту обе части должны быть всегда и создаваться вместе.
Так же на всякий случай должен быть способ исключения операций из таблиц(например таблица истории явно не должна иметь редактирования)
1)Например про атрибуты в модели, то что вам так нравится не значит что так должны делать все, понятное дело что в вашем инструменте будут преобладать ваши вкусы, но не проецируйте их на других.
Что плохого в атрибутах в модели? Я вправе создавать какие угодно атрибуты, если это улучшает качество и читаемость кода.
Связь модели моделей БД и моделей из MVC - уже другой вопрос. Скорость разработки vs устойчивость к изменениям.
1)Способов описания модели БД у EF действительно несколько, я например не люблю атрибутами описывать модели, мне проще структуру видеть в одном месте.
Ну я и написал что это единственный приемлемый вариант. Искать таблицы и как они появляются в проекте - не совсем удачный вариант.
Поддержка OwnedEntity, ManyToMany.
Я начал с простейшего, думаю добавлю это ко второй части статьи. Тем более все это описывается либо как IEnumerable<T>, либо как T. Где T - модель данных другой таблицы.
Я что-то не могу найти: а Fluent API ваш генератор поддерживает?
Опять же, рефлексия для того и создана чтобы получать информацию о типе.
Я рад что кто-то сможет построить и запустить какой-нибудь DbContext с единственным конструктором, принимающем ICustomConfigurationService. И выполнить в нем методы, неизвестные большинству (GetTables или аналоги).
И все равно остаться без необходимых атрибутов полей.
Но это, увы - обходной путь.
Делаем свой генератор CRUD для asp.net mvc (часть 1 — получаем данные)