Этими двумя функциями, добавленными для поддержки генераторов кода, являются расширения для синтаксиса разделяемого метода _ и _инициализаторов модулей**. Сначала рассмотрим изменения в разделяемые методы. До C# 9.0 разделяемые методы были private, но не могли иметь модификаторов доступа, иметь возвращаемое значение void и параметры out. Эти ограничения подразумевают, что, если реализация метода не предоставлена, компилятор удаляет все вызовы к разделяемому методу. В C# 9.0 эти ограничения снимаются, но требуется, чтобы объявления разделяемых методов имели реализацию. Генераторы кода могут предоставить такую реализацию. Чтобы избежать критических изменений, компилятор рассматривает любой разделяемый метод без модификатора доступа как метод, следующий старым правилам. Если разделяемый метод включает модификатор доступа private, этот разделяемый метод обрабатывается в соответствии с новыми правилами.
Второй новой функцией для генераторов кода являются инициализаторы модулей. Инициализаторы модулей — это методы, к которым прикреплен атрибут ModuleInitializerAttribute. Эти методы будут вызываться средой выполнения до доступа к полю или вызова метода в целом модуле. Метод инициализатора модуля:
должен быть статическим;
должен быть без параметров;
должен возвращать значение void;
не должен быть универсальным методом;
не должен содержаться в универсальном классе;
должен быть доступен из содержащего модуля.
Последний пункт фактически означает, что метод и содержащий его класс должны быть внутренними или открытыми. Метод не может быть локальной функцией.
Здравствуйте, varenikAA, Вы писали:
AA>Подумал, стоит попробовать генерить рекорды по базе данных. вроде должно получиться?
Получится может, но пользоваться будет нельзя. Пару косяков с ходу:
— долгий коннект к базе во время "каждой" компиляции, генерация кода "не лету" для, например, четырёхсот таблиц.
— проблемы с доступом к генерируемой БД различными билд серверами.
— изменение структуры БД коллегой во время вашей работы, что может лекго привести к некомпилируемому коду у вас.
— генерация кучи нежелательного мусора.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Ночной Смотрящий, Вы писали:
IT>>- долгий коннект к базе во время "каждой" компиляции, генерация кода "не лету" для, например, четырёхсот таблиц. IT>>- проблемы с доступом к генерируемой БД различными билд серверами. IT>>- изменение структуры БД коллегой во время вашей работы, что может лекго привести к некомпилируемому коду у вас.
НС>Это можно полечить двухэтапной генерацией. Отдельно контроллируемо выгружаем схему в некий универсальный формат, а генераторы уже работают по лежащей в проекте схеме.
Замечательно. Хождение компилятора в БД решительно отметаем. Тогда прикинем варианты.
— Во многих проектах структура БД уже выгружена и находится в проекте в виде DDL. Т.е. компилятор (генератор) должен уметь парсить и корректно разбирать разные диалекты DDL разных СУБД. Тоже так себе идея.
— Выгрузка в JSON/XML. Т.е. дополнительный шаг для разработчика всё же присутсвует и по сути ничем не отличается от генерации кода сразу, но при этом всё же имеет один недостаток, о котором ниже.
В принципе, второй вариант приемлем, если в проекте используется какой-нибудь визуальный редактор, из которого обновляется схема БД и который держит данные в таком формате. Но в данном случае мы опять получаем решение заточенное именно под этот редактор.
Теперь два главных вопроса.
1. Что полезного мы получаем, используя данный подход?
2. Что плохого случится, если мы не используем данный подход?
По первому вопросу у меня только один вариант — это хороший опыт для разработчика такого генератора. Не более.
По второму — ничего.
IT>>- генерация кучи нежелательного мусора. НС>Здесь не понял
По моему опыту работы с большими БД в больших командах, исходная БД, по которой генерируется схема редко находится в идеальном состоянии. Кому-нибудь когда-нибудь обязательно понадобится добавить туда что-нибудь на время или поэкспериментировать. Чтобы не тащить такой хлам в сгенерированный код, необходимо делать ревью сгенерированного кода и комитить в репозиторий только собственные изменения. Это, кстати, решает и проблему в третьем пункте из моего предыдущего поста. И возвращаясь к JSON/XML — ревью гораздо проще делать, если это исходный код, а не JSON/XML.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, varenikAA, Вы писали:
AA>>Подумал, стоит попробовать генерить рекорды по базе данных. вроде должно получиться?
IT>Получится может, но пользоваться будет нельзя. Пару косяков с ходу:
IT>- долгий коннект к базе во время "каждой" компиляции, генерация кода "не лету" для, например, четырёхсот таблиц. IT>- проблемы с доступом к генерируемой БД различными билд серверами. IT>- изменение структуры БД коллегой во время вашей работы, что может лекго привести к некомпилируемому коду у вас. IT>- генерация кучи нежелательного мусора.
Здравствуйте, IT, Вы писали:
IT>Да, извини, я не всё упомянул. Экзотика, бардак или всякие извращенства.
Экзотика — это у тебя, когда ты сидишь и пилишь систему с одной единственной инсталляцией для одного единственного банка. Эдакие мегадинозавры в эпоху разделения труда.
Действительно ли это новая технология метапрограммирования от МС как указал докладчик.
Подумал, стоит попробовать генерить рекорды по базе данных. вроде должно получиться?
Смущает только что видимо без partial class в качестве затравки забуксует сие творение.
Здравствуйте, Serginio1, Вы писали:
S> Кстати Оживляем деревья выражений кодогенерацией
Прикольно. Что-то такое мне как раз приходило в голову сразу после анонса генераторов; а вот тут люди взяли — и написали. Толково.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, IT, Вы писали:
IT>- долгий коннект к базе во время "каждой" компиляции, генерация кода "не лету" для, например, четырёхсот таблиц. IT>- проблемы с доступом к генерируемой БД различными билд серверами. IT>- изменение структуры БД коллегой во время вашей работы, что может лекго привести к некомпилируемому коду у вас.
Это можно полечить двухэтапной генерацией. Отдельно контроллируемо выгружаем схему в некий универсальный формат, а генераторы уже работают по лежащей в проекте схеме.
IT>- генерация кучи нежелательного мусора.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это можно полечить двухэтапной генерацией. Отдельно контроллируемо выгружаем схему в некий универсальный формат, а генераторы уже работают по лежащей в проекте схеме.
Имхо, тогда проще в момент выгрузки схемы сразу всё и сгенерировать и в момент компиляции уже не заморачиваться.
Другое дело, что если генерация идет не просто по всей структуре базы или есть некие условия (например, параметры генерации) которые могут выход генератора менять — тогда да.
Ну или, как вариант, если для разработки базы используется что-то типа SSDT-проекта, то можно запросто брать за основу схему базы оттуда. Он, конечно, тоже не мгновенно собирается, но это, куда практичнее, чем подключаться к базе.
НС>Здесь не понял
Видимо, имелось в виду, что если процесс генерации не настраивать как-то явно, то в результатах генерации будут появляться: левые таблицы, всякие служебные поля (которые нам ни разу не сдались и с уровня БД их нафиг не нужно забирать).
А если ввести такую "настройку", то возникает вопрос — а будет ли выигрыш от генерации? Не будет ли проще всё аккуратно прописать руками (ну при условии, что нам нужно генерировать именно только DTO, а не еще и всё слои доступа к БД).
Здравствуйте, Михаил Романов, Вы писали:
НС>>Это можно полечить двухэтапной генерацией. Отдельно контроллируемо выгружаем схему в некий универсальный формат, а генераторы уже работают по лежащей в проекте схеме. МР>Имхо, тогда проще в момент выгрузки схемы сразу всё и сгенерировать
Это от подхода зависит. Если ты руками правишь модель, а по ней генеришь скрипты для БД и исходники (а при необходимости миграций к чему то такому ты в итоге и придешь), схема с моделью будет поудобнее.
МР>Ну или, как вариант, если для разработки базы используется что-то типа SSDT-проекта, то можно запросто брать за основу схему базы оттуда.
Здравствуйте, IT, Вы писали:
НС>>Это можно полечить двухэтапной генерацией. Отдельно контроллируемо выгружаем схему в некий универсальный формат, а генераторы уже работают по лежащей в проекте схеме. IT>Замечательно. Хождение компилятора в БД решительно отметаем.
Это довольно глупо, хотя бы потому что лезть в БД с билд машин совсем неразумно, замахаешься их версии плодить.
IT>- Во многих проектах структура БД уже выгружена и находится в проекте в виде DDL.
А это вот фиг знает в каком виде оно в проекте. Бывает очень по разному. В моем текущем, к примеру, оно в виде кода на шарпе в миграциях FluentMigrator.
IT>По моему опыту работы с большими БД в больших командах, исходная БД, по которой генерируется схема редко находится в идеальном состоянии.
Идея опираться на структуру реальной БД в целом тоже довольно стремная и подходит только для проектов с одним единственным деплойментом и линейной историей. Как только у тебя появляется несколько деплойментов про генерацию по какой то образцовой БД можно сразу забыть, что с компилятором, что без него.
Здравствуйте, Ночной Смотрящий, Вы писали:
IT>>- Во многих проектах структура БД уже выгружена и находится в проекте в виде DDL. НС>А это вот фиг знает в каком виде оно в проекте. Бывает очень по разному. В моем текущем, к примеру, оно в виде кода на шарпе в миграциях FluentMigrator.
О том и речь.
IT>>По моему опыту работы с большими БД в больших командах, исходная БД, по которой генерируется схема редко находится в идеальном состоянии. НС>Идея опираться на структуру реальной БД в целом тоже довольно стремная и подходит только для проектов с одним единственным деплойментом и линейной историей. Как только у тебя появляется несколько деплойментов про генерацию по какой то образцовой БД можно сразу забыть, что с компилятором, что без него.
Это как раз либо экзотика, либо бардак. Хотя для кого-то и то и другое могут быть обычными реалиями
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это от подхода зависит. Если ты руками правишь модель, а по ней генеришь скрипты для БД и исходники (а при необходимости миграций к чему то такому ты в итоге и придешь), схема с моделью будет поудобнее.
Так — согласен.
Но это прямо противоположно тому, что предлагал ТС (он хотел по существующей БД генерировоать код)
НС>SSDT хранит схему БД в специальной локальной БД.
Хм... Видимо я давно с SSDT не работал.
Раньше схема была такой:
— сам проект это просто набор SQL-исходников (ну и немного доп. информации в файле проекта)
— в результате сборки проекта создается пакет .dacpac, в котором лежит структурированное представление схемы (которая из этих исходников и была получена) + оставшиеся скрипты, которые схемой не описываются (обычно это всякие pre-/post- деплойные скрипты с данными или еще чем...)
— для разработки/отладки можно было накатывать этот пакет прямо из студии и по умолчанию предлагалось в качестве целевой использовать инстанс SQL LocalDB (но это без проблем можно был и поменять).
Там, конечно, сам SSDT в процессе работы создает некие промежуточные файлы (и наверняка там структура базы/проекта как-то представлена — вы о них?), но те файлы для использования извне мало пригодны — что там внутри нигде не описано.
Нет, я имел в виду, что структуру базы можно спокойно читать из собранного .dacpac — всё API для этого опубликовано (там, конечно, то API абсолютно нечеловеческое, но есть вполне обкатанные обертки типа DACExtensions — которые уже вполне нормальные (ну на фоне исходного API
Здравствуйте, IT, Вы писали:
IT>Это как раз либо экзотика, либо бардак.
Какая ж это экзотика? Наличие параллельных релизов, например следующий мажорный и хотфикс к предыдущему мажорному — вполне себе норма, особенно если мы про онпрем говорим.
Здравствуйте, Ночной Смотрящий, Вы писали:
IT>>Это как раз либо экзотика, либо бардак. НС>Какая ж это экзотика? Наличие параллельных релизов, например следующий мажорный и хотфикс к предыдущему мажорному — вполне себе норма, особенно если мы про онпрем говорим.
Да, извини, я не всё упомянул. Экзотика, бардак или всякие извращенства.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, alexzzzz, Вы писали: A>Термин "универсальный" всегда был? Их вроде раньше называли обобщёнными. Или это был сленг, а я не в курсе?
Это перевод нейросеткой. Обнять, поплакать, заменить в URL ru-RU на en-US.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, alexzzzz, Вы писали: A>>Термин "универсальный" всегда был? Их вроде раньше называли обобщёнными. Или это был сленг, а я не в курсе? S>Это перевод нейросеткой. Обнять, поплакать, заменить в URL ru-RU на en-US.
Здравствуйте, alexzzzz, Вы писали:
A>Здравствуйте, Serginio1, Вы писали:
S>>не должен быть универсальным методом; S>>не должен содержаться в универсальном классе;
A>Термин "универсальный" всегда был? Их вроде раньше называли обобщёнными. Или это был сленг, а я не в курсе?
Ну видно ИИ еще не дошел до правильного перевода.
Generic Methods (C# Programming Guide)
Универсальные методы (Руководство по программированию на C#)
и солнце б утром не вставало, когда бы не было меня
Если нам не помогут, то мы тоже никого не пощадим.
