Опять же, рефлексия для того и создана чтобы получать информацию о типе.
Я рад что кто-то сможет построить и запустить какой-нибудь DbContext с единственным конструктором, принимающем ICustomConfigurationService. И выполнить в нем методы, неизвестные большинству (GetTables или аналоги).
И все равно остаться без необходимых атрибутов полей.
Так вот, составление матмоделей, идентификация параметров (в т.ч. используя методы машинного обучения) - это средняя ЗП в районе 2-4 к$.
Это пока вы получаете образование.
В общем направление называется Цифровые двойники, и там все несколько сложнее, чем использовать SciPy. (И с СуперНейросетью вас тоже скорее всего погонят).
Да, кстати, а вы знаете сколько энергии потребляет 1 цех?
1)Например про атрибуты в модели, то что вам так нравится не значит что так должны делать все, понятное дело что в вашем инструменте будут преобладать ваши вкусы, но не проецируйте их на других.
Что плохого в атрибутах в модели? Я вправе создавать какие угодно атрибуты, если это улучшает качество и читаемость кода.
Связь модели моделей БД и моделей из MVC - уже другой вопрос. Скорость разработки vs устойчивость к изменениям.
1)Способов описания модели БД у EF действительно несколько, я например не люблю атрибутами описывать модели, мне проще структуру видеть в одном месте.
Ну я и написал что это единственный приемлемый вариант. Искать таблицы и как они появляются в проекте - не совсем удачный вариант.
Поддержка OwnedEntity, ManyToMany.
Я начал с простейшего, думаю добавлю это ко второй части статьи. Тем более все это описывается либо как IEnumerable<T>, либо как T. Где T - модель данных другой таблицы.
При том, у вас в общем-то ваша рисовалка CRUD вообще не должна предъявлять никаких дополнительных требований к источникам данных?
Прямая аналогия - напишите свою конфигурацию для CCleaner.
Не вижу нарушения.
Ядро системы и разработка ядра системы (слоя с данным и бизнес логики) начинает зависеть от написания сервисов со странным интерфейсом для работы вашей утилиты.
Замечательная архитектура.
И вы мне пытаетесь это доказать на протяжении 20 сообщений.
Один предложил добавить реализацию интерфейса IDesignTimeDbContextFactory к каждому экземпляру DbContext, чтобы строить экземпляр DbContext. (И вытаскивать данные о таблицах и прочем)
Второй считает что CRUD, списки и формочки бизнесу не нужны. Видимо существует другой, особый подход, основанный не на объектах и их списках.
Давайте в бизнес посмотрим. Какие задачи это решает? Можно ли интернет-магазин сделать за 2 часа? Бухгалтерскую систему? Складской учёт? Да хоть бы тупейший TODO-менеджер?
А зря, кругозор лишним не бывает, особенно когда вы берётесь делать громкие заявления относительно того как другие должны писать их код.
Увы, на среднюю сертификацию разработчика на .net надо знать гораздо меньше.
Все классы (и их поведение) узнать невозможно.
Плюс фабрика крайне неудобна. (и как выяснилось еще и специфична). Я прочел более 4-х толстенных книг по шарпу и ни разу не слышал про данный интерфейс.
Тем более появляется новое требование
Реализацию IDesignTimeDbContextFactory должен написать тот, кто пишет контекст.
Увы, скорее всего большинство DbContext_ов на проекте будет либо уже без IDesignTimeDbContextFactory, либо без конструкторов без аргументов, либо никто даже не будет реализовывать подобный интерфейс.
А где реализации упомянутого 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 DbContext or 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.
И это - основы ООП. Если что то принимается в конструкторе, это что-то из конструктора может использоваться.
Начиная от примитивных текстовых форумов заканчивая подписками на сервис ChatGPT - все строится на списках, элементах, связанных списках, которые хранятся в базе данных.
Формочки сами по себе никому не нужны, за ними большой слой логики.
Ага, и логика эта - или валидация, или события (и их обработчики). Вот это поворот. Или отдельные микросервисы.
Ну давайте копнём глубже. Вы накидали за 2 часа условно супер-универсальный CRUD. Подойдём основательно и выделим больше времени. Допустим 2 недели. Сделали CRUD, теперь можно редактировать любые таблички, вносить данные. Что дальше? :) Можно разогнать табун разработчиков. Теперь можно вводить любые данные. Программа готова на века :)
Все, добавляю IdentityServer и раздаю права. Делаю описания таблиц и прав на json. Назовите мне что я не смогу сделать :). (или значительно ускорить разработку, как и наивно полагали инженеры Microsoft, когда делали свой генератор CRUD)
Похоже в Microsoft-то дураки набитые сидят, и делают генераторы формочек :)
Если вам удобен всего 1 вариант — это не означает что он удобен для всех
Конечно, репозиторий BrainFuck-а довольно популярен. Однако даже при поддержке всякие чудеса вроде "Ой, а классы унаследованные от Control не надо регистрировать в контейнерах" - да, если это asp net, это может быть терпимо. Если у вас в Бэкенде на добрую сотню-две тысяч строк таблицы(!) можно добавлять из нескольких точек(настолько часто меняется схема данных?!) - это уже не отлаживается и не поддерживается.
Потому что найти все ссылки на вызов метода и найти 10 вариантов реализации одной и той же функциональности - это разница в 10 раз по времени.
Не говоря уже о том, что если эти практики попадут в OpenSource и будет поддержка со стороны IDE - тогда может еще терпимо. Но если это Ваш код, который не фиксирует точки функциональности - это конец проекта.
А может, всё-таки погуляете по ссылкам в документации?
Погуглил, не нашел методов GetTables, GetLinks и подобных. И написал аж 200 строк кода :)
При том, что вы во всех комментариях пишете тут именно про таблицы, а не про сущности. Вот мне и показалось что вам нужны именно они.
Да нет, мне нужны таблицы из контекста и описание моделей данных(сущности). А так же вся необходимая информация из сущностей.
Опять же, рефлексия для того и создана чтобы получать информацию о типе.
Я рад что кто-то сможет построить и запустить какой-нибудь DbContext с единственным конструктором, принимающем ICustomConfigurationService. И выполнить в нем методы, неизвестные большинству (GetTables или аналоги).
И все равно остаться без необходимых атрибутов полей.
Но это, увы - обходной путь.
Вы о PhD vacancy слышали? )
Так вот, составление матмоделей, идентификация параметров (в т.ч. используя методы машинного обучения) - это средняя ЗП в районе 2-4 к$.
Это пока вы получаете образование.
В общем направление называется Цифровые двойники, и там все несколько сложнее, чем использовать SciPy. (И с СуперНейросетью вас тоже скорее всего погонят).
Да, кстати, а вы знаете сколько энергии потребляет 1 цех?
Что плохого в атрибутах в модели? Я вправе создавать какие угодно атрибуты, если это улучшает качество и читаемость кода.
Связь модели моделей БД и моделей из MVC - уже другой вопрос. Скорость разработки vs устойчивость к изменениям.
Ну я и написал что это единственный приемлемый вариант. Искать таблицы и как они появляются в проекте - не совсем удачный вариант.
Я начал с простейшего, думаю добавлю это ко второй части статьи. Тем более все это описывается либо как IEnumerable<T>, либо как T. Где T - модель данных другой таблицы.
Увы, смена ORM практически не происходит за время жизни проекта. Поэтому и не пишут еще 10 классов\интерфейсов для обобщения моделей.
Наваливать дополнительные обязанности на разработчиков ядра бизнес-логики при помощи утилиты - вы в своем уме?
Вы много различных ORM использовали в своей работе?
При том, у вас в общем-то ваша рисовалка CRUD вообще не должна предъявлять никаких дополнительных требований к источникам данных?
Прямая аналогия - напишите свою конфигурацию для CCleaner.
Ядро системы и разработка ядра системы (слоя с данным и бизнес логики) начинает зависеть от написания сервисов со странным интерфейсом для работы вашей утилиты.
Замечательная архитектура.
И вы мне пытаетесь это доказать на протяжении 20 сообщений.
Какой гугл обратно? )
Яндекс же вообще Израиль (шахматы, наука, а не шавки какие-то).
А задача великий бойцов с пришизевшими фашиствующими зомби (ха ха ха) - охрана страны, и с этим великие спецслужбы не справляются.
С проигранной "Спецоперацией" нападки на частные фирмы еще смешнее смотрятся.
Нет, один демультиплексор 4 бита в 16 линий это скорее всего16 масок на эти самые 4-хбитные значения (потому что задержка играет важную роль).
или примерно 4 транзистора на 1 вывод (линию).
У меня 2 транзистора на линию с той же задержкой (4 FO-4).
Для тех, кому лень читать весь срач -
Один предложил добавить реализацию интерфейса IDesignTimeDbContextFactory к каждому экземпляру DbContext, чтобы строить экземпляр DbContext. (И вытаскивать данные о таблицах и прочем)
Второй считает что CRUD, списки и формочки бизнесу не нужны. Видимо существует другой, особый подход, основанный не на объектах и их списках.
Нет, Demux tree скорее просто похоже. (потому что дерево, и демультиплексор)
Тем более демультиплесирование идет на каждом шаге DemuxTree
То есть там, в приложении, какие-то объекты, которые или выводятся списками, или добавляются? :)
Или де-факто стандарт - управление из игры Darwinia? )
Бизнес и люди работают с сущностями из таблиц.
Вы - сторонник написания всего руками?
Как ни странно.
Очень просто, давно писали конфиги для CCleaner? )
Это нарушает цепочку зависимостей - объекты зависят от инструментов и утилит, а не наоборот.
Тем более надо всего-лишь написать 200 строк кода, и не смотреть на "пользовательские реализации интерфейса для создания экземпляров DbContext".
Ну да, конечно )
Увы, на среднюю сертификацию разработчика на .net надо знать гораздо меньше.
Все классы (и их поведение) узнать невозможно.
Плюс фабрика крайне неудобна. (и как выяснилось еще и специфична). Я прочел более 4-х толстенных книг по шарпу и ни разу не слышал про данный интерфейс.
Тем более появляется новое требование
Увы, скорее всего большинство DbContext_ов на проекте будет либо уже без IDesignTimeDbContextFactory, либо без конструкторов без аргументов, либо никто даже не будет реализовывать подобный интерфейс.
А на python-е тоже дураки пишут?
Народ говорит там уже генераторы CRUD на уровне средней админки.
А где реализации упомянутого IDesignTimeDbContextFactory?
Ок, то есть мне надо еще сконструировать этот самый DbContext. (который я скорее всего потяну как зависимость откуда-то, учитывая сказанное вами).
Без ConnectionString или как-то еще.
И не прострелить себе ногу вызывая эти методы?
Тем более опять появилась сущность которая работает без каких-либо связей в коде, что является плохой практикой.
Нет, равно как я еще не в курсе относительно оставшихся 10 тысяч классов внутри библиотеки .net.
И тем более деталей реализации. (Потребуется ли подключение к БД или нет?).
Поэтому я выбрал надежный способ - получить все через рефлексию. И получил. Тем более без потраченных 30 минут тяжело сказать (да и в документации это не описано) когда потребуется ConnectionString.
И это - основы ООП. Если что то принимается в конструкторе, это что-то из конструктора может использоваться.
Это если не вдаваться в теорию. Что для одинаковых сущностей достаточно написать код 1 раз, чтобы обработать бесконечное множество сущностей.
А сущности это абстракции на основе реальный объектов имеющие общие свойства, параметры, и прочее, выведенный статистически.
То же самое с комбинациями сущностей.
И вот, мы создаем язык lisp.
А чтобы добавлять или просматривать эти самые сущности, нам нужен CRUD, желательно работающий со ссылками на другие таблицы.
И статьи на хабре, и связанные 1 to N комментарии - тоже лежат в области генерации формочек.
Похоже, только:
1) Биты адреса не изменяются после этапа начальной декодировки. И вообще с такой системой счисления у меня нет декодировки :)
2) везде и всюду постоянный коэффициент ветвления (а не FO-256 для последних бит адреса)
3) как следствие предыдущего пункта - малое потребление энергии
4) Работает так же быстро как и быстрейшие демультиплексоры из ucdavis
5) Имеет на 20% меньшую площадь
Вот сравнения различных типов между собой
https://github.com/ValeriyAndreevichPushkarev/Selector_8bit/
Дерево демультиплесоров демультиплесирует на каждом шаге. Там кстати получится больше 2-х транзисторов на линию и скорее всего даже больше задержка
Да ладно, мне в соседней теме пишут генератор CRUD нахой ненужон :)
Дефицита нет? )
Давайте по пунктам - CRUD есть везде.
Начиная от примитивных текстовых форумов заканчивая подписками на сервис ChatGPT - все строится на списках, элементах, связанных списках, которые хранятся в базе данных.
Ага, и логика эта - или валидация, или события (и их обработчики). Вот это поворот. Или отдельные микросервисы.
Все, добавляю IdentityServer и раздаю права. Делаю описания таблиц и прав на json. Назовите мне что я не смогу сделать :). (или значительно ускорить разработку, как и наивно полагали инженеры Microsoft, когда делали свой генератор CRUD)
Похоже в Microsoft-то дураки набитые сидят, и делают генераторы формочек :)
https://www.sumologic.com/glossary/crud/#:~:text=with Sumo Logic-,What is CRUD%3F,%2C read%2C update and delete.
Конечно, репозиторий BrainFuck-а довольно популярен. Однако даже при поддержке всякие чудеса вроде "Ой, а классы унаследованные от Control не надо регистрировать в контейнерах" - да, если это asp net, это может быть терпимо. Если у вас в Бэкенде на добрую сотню-две тысяч строк таблицы(!) можно добавлять из нескольких точек(настолько часто меняется схема данных?!) - это уже не отлаживается и не поддерживается.
Потому что найти все ссылки на вызов метода и найти 10 вариантов реализации одной и той же функциональности - это разница в 10 раз по времени.
Не говоря уже о том, что если эти практики попадут в OpenSource и будет поддержка со стороны IDE - тогда может еще терпимо. Но если это Ваш код, который не фиксирует точки функциональности - это конец проекта.
Погуглил, не нашел методов GetTables, GetLinks и подобных. И написал аж 200 строк кода :)
Да нет, мне нужны таблицы из контекста и описание моделей данных(сущности). А так же вся необходимая информация из сущностей.