В статье об этом есть - использовал генераторы не заметил тормозов. Инкрементальные пока не смотрел.
В статье об этом есть - хочу по доменным сущностям все сделать. При этом хочу чтобы сгенерированный код лежал где надо (в Infrastructure.Web, например. А атрибуты для аннотации в Domain.Common). Где вы тут антипаттерн нашли(и как он называется)? xD
Опять же, рефлексия для того и создана чтобы получать информацию о типе.
Я рад что кто-то сможет построить и запустить какой-нибудь 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.
И это - основы ООП. Если что то принимается в конструкторе, это что-то из конструктора может использоваться.
В статье об этом есть - использовал генераторы не заметил тормозов. Инкрементальные пока не смотрел.
В статье об этом есть - хочу по доменным сущностям все сделать. При этом хочу чтобы сгенерированный код лежал где надо (в Infrastructure.Web, например. А атрибуты для аннотации в Domain.Common). Где вы тут антипаттерн нашли(и как он называется)? xD
Бред-то какой.
Увы, не нужен TSQL.
Недавно видел таких разработчиков (которые, увы, не смогли в DDD :)).
Dapper не быстрее, чем EF Core во всех кейсах. (CRUD, деревья, и т.д.)
А разработка на EF Core (Linq) почему-то раза в 2-3 быстрее, чем "Править поля запросам в Dapper", не говоря уже про удобство поддержки.
А если еще правильно делать Include (и не возвращать по 10 мб с сервера) - то быстрее во всех случаях.
Даже rte быстрее с EF Core (да, обертка для работы с деревьями делается на раз).
А от того, что вы не вернете 4 лишних поля запросы, увы, не ускоряются :)
Большинство бизнес-офисов(и бизнес центров) не имеют даже нормальной вентиляции (вытяжки, приточки). Не говоря уже про расположение мониторов и проч.
И работать там тяжело даже без сумасшедших, которые туда набиваются :)
(Ведь даже без всех приколов получается гипоксия и\или бред людей с гипоксией
(
Dapper, MongoDb, контроллеры пишем руками, тесты не нужны))Европа\США же очень отличается в этом плане.
(
Особенно без дешевого газа, и с LGBT)(del)
Опять же, рефлексия для того и создана чтобы получать информацию о типе.
Я рад что кто-то сможет построить и запустить какой-нибудь 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 комментарии - тоже лежат в области генерации формочек.