На почту упала очередная новость о мелкомягких продуктах жизнедеятельности — статья "генерирование кода из XAML".
Могу ошибаться, но сухая выжимка статьи состоит в следующем (идёт в контексте MVVM):
У нас есть полусырая ViewModel. Мы создали некую форму. Положили на неё контрол-редактор. Теперь сама магия: мы делаем байндинг этого контрола на несуществующее свойство объекта. Затем кликаем на байндинг и он предлагает добавить хрен знает куда атрибут x:DataType, который говорит, с каким типом ассоциирована вся форма. Затем ещё раз надо кликнуть на bulb вашего байндинга, где он предложит "Create property 'ваше несуществующее проперти'". После чего в ваш класс насрут целый метод SetProperty и добавят проперть. Всё, магия окончена.
Фактически, это "сниппет через задницу", где во ViewModel предлагают вносить штампованый код (который давно должен быть в .NET'е, а не в коде). Только делается это не из редактора (как положено), а из XAML (будто это хоть на грош упрощает задачу!). Опять наступает эпоха формошлёпства?? (когда чел не думает о коде, а тупо шлёпает контролы на форму)
Повторюсь, возможно я ошибаюсь и это гиперфича, но в моей практике код никогда так не пишется! Model/ViewModel всегда корректируются и синхронизируются только через редактор! (и зависит от базы, т.е. ещё одно далёкое от формы место!)
Здравствуйте, Kolesiki, Вы писали: K> и он предлагает добавить хрен знает куда атрибут
Вот поэтому и не стоит модель от представления отделять. все должно быть в одном файле.
K>Могу ошибаться, но сухая выжимка статьи состоит в следующем (идёт в контексте MVVM):
MVVM — для чего используется эта штука?
Поводов так извращаться всего 2:
1. xaml фигачит дизайнер. модельку кодер.
2. представлений несколько.
Обвчно же
представление одно в течении всей жизни приложения.
и вдобавок используется автосвязывание модели и представления, т.е. 2 пункт в этом случае совсем не нужен.
Т.е. если не заморачиваться с MVVM, то ни велосипед с инстанцированием не нужен, ни разделение на модель и предстваление.
В таких штуках лучше работает метапрограммирование.
Вот взять любой нормальный ФВ в js (реакт, вью, свелте — в порядке появления),
все они шли к одному — уменьшения кол-ва кода. и сейчас нормальная страница в свелте занимает один экран все вместе: логика, разметка, стили.
Вот к чему нужно стремиться. Но в дотнете до сих пор нет маркосов, а это все что нужно чтобы метапрограммирование было производительным и простым.
донет-рефлексия мягко говоря обделалась. Ее практически не используют, потому что метапрограммирование это чуждая для дотнетчиков тема.
Здравствуйте, varenikAA, Вы писали:
AA>Вот к чему нужно стремиться. Но в дотнете до сих пор нет маркосов, а это все что нужно чтобы метапрограммирование было производительным и простым. AA>донет-рефлексия мягко говоря обделалась. Ее практически не используют, потому что метапрограммирование это чуждая для дотнетчиков тема.
Нет макросов но при этом кодогенерация присутствует полным ходом в самой студии или через а те же T4.
Рефлексия используется полным ходом и от неё особо то и отказываться не хотят. Поэтому и тормозит CoreRT, хотя .Net Native как минимум 4 года.
Ну сейчас для таких как ты есть Using C# Source Generators to create an external DSL
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Хэлкар, Вы писали:
Х>Никто вас не заставляет это фичей пользоваться.
Узколобо мыслишь, юный подаван! За каждой фичей, которую выкатывает MS, стоит (хотя бы теоретически) целый конвейер околопрограммистских людей, которые "придумывают фичи", обсуждают с боссом, вносят в планы, реализуют, тестируют на кошках внешних программистах (ну не за свои же деньги это делать!), документируют, пишут дифирамбы (как статья в начальной ссылке), потом снова это обсасывают отлаживают из-за поспешности реализации и бестолковой архитектуры и так по кругу.
Другими словами, уходит ТОННА РЕСУРСОВ на такую позорную шнягу, что начинаешь думать, будто действительно за эти фичи голосует какой-нть осьминог! И не было бы проблем и подгораний пуканов, если бы ВСЁ ОСТАЛЬНОЕ было бы на высоте! Но нет, в пуле реквестов ГОДАМИ лежат полезные запросы и хоть бы одна обезьяна просто прочла их и подумала — ведь действительно удобно! Эту фичу ведь запрашивают реальные программисты, а не придумывают макаки из "Маркетинга"! Уж наверное эта фича куда важнее ФОРМОШЛЁПСТВА!
Х> Формошлепство нужно. Кто-то должен этим заниматься и МС просто пытается упростить им жизнь.
Ну да. Как бейсик, который они тянули годами и который надо уже просто собраться и ВЫКИНУТЬ!
Не путайте "формошлёпство" и "удобство визуальной разработки" — это разные вещи. И то, что прикрутили мелкомягкие — оно вообще из разряда "почесать правое ухо левой ногой", хотя и сделано типа как помощь.
Вот если ты кладёшь на форму кнопку и удобно по месту регулируешь её свойства — это "визуальная помощь". А если ты положил туда грид, а тебе в проект насыпали две тонны Enterprise Framework'а и за тебя сгенерили какую-то кодовую лажу — это уже формошлёпство. Почувствуй разницу!!
Вот какой смысл был мелкософту заигрывать с опенсорсом? ХОТЬ ЧТО-ТО изменилось?? Реквесты как лились десятками, так и льются — никто ничего не делает. Как юзеры были отстранены от голосования за фичи — так и осталось. Нет, за сам реквест голосовалка есть! Но её нет при ПРИНЯТИИ В РАЗРАБОТКУ. Вот кто решает какую именно фичу делать в этом месяце? Ты? Я? Нет! Решает офисный долбоклюй, которого привезли с далёкой Индии и который сам ссыт, насколько фича может быть сложной по реализации. Поэтому выбирается самая простейшая шняга и пилится, рапортуя наверх "у нас появилось больше фич, милорд!". ПОЭТОМУ важные вещи пылятся в реквестах, но при этом, ***ка, ВСЕ ЗАНЯТЫ! ЧЕМ?? Прально — формошлёпством! Да протухнет сия контора быстрее, чем разорит инвесторов.
Второе, мне ваше высокомерие в хер не уперлось, засуньте его туда откуда вынули.
Третье, не нравится — вперед, форкаете весь дотнет и делаете свои фичи для себя.
Четвертое, даже если вы за свои деньги купили вижуалстудию, вас никто не заставлял. Не нравится — вперед, языков программирования и сред для них десятки, на любой вкус.
Обычно любому коду нужна организация.
Обычно если речь о десктопе, то тем более будет трудно воспринимать один файл.
AA>представление одно в течении всей жизни приложения.
Нет.
AA>Т.е. если не заморачиваться с MVVM, то ни велосипед с инстанцированием не нужен, ни разделение на модель и предстваление.
Успеха в работе с такими портянками.
AA>все они шли к одному — уменьшения кол-ва кода. и сейчас нормальная страница в свелте занимает один экран все вместе: логика, разметка, стили.
Здравствуйте, Serginio1, Вы писали:
S> Нет макросов но при этом кодогенерация присутствует полным ходом в самой студии или через а те же T4. S>Рефлексия используется полным ходом и от неё особо то и отказываться не хотят. Поэтому и тормозит CoreRT, хотя .Net Native как минимум 4 года.
Тормозили, тормозим и будем тормозить! S>Ну сейчас для таких как ты есть Using C# Source Generators to create an external DSL
Ну не знаю, очень сложно в понимании, нужно partial class использовать, куски исходников в строках
вот это проще, но тоже не все случаи закрывает: https://github.com/pamidur/aspect-injector
Здравствуйте, IncremenTop, Вы писали:
IT>Чем отличается тонкий клиент от толстого?
В каком контексте? Если софт, то я представляю толстый — это десктоп нативный.
тонкий это ПО которое внутри толстого. ну те вебапп.
Здравствуйте, varenikAA, Вы писали:
AA>Здравствуйте, Serginio1, Вы писали:
S>> Нет макросов но при этом кодогенерация присутствует полным ходом в самой студии или через а те же T4. S>>Рефлексия используется полным ходом и от неё особо то и отказываться не хотят. Поэтому и тормозит CoreRT, хотя .Net Native как минимум 4 года. AA>Тормозили, тормозим и будем тормозить!
Ну почему же. Деревья выражений быстро работают. А они без среды выполнения не могут создаваться.
S>>Ну сейчас для таких как ты есть Using C# Source Generators to create an external DSL
AA>Ну не знаю, очень сложно в понимании, нужно partial class использовать, куски исходников в строках AA>вот это проще, но тоже не все случаи закрывает: https://github.com/pamidur/aspect-injector
Почему обязательно в строках? можешь и в базе данных
А что по поводу Source Generators, то дает тебе в руки свой инструмент.
Тот же fody делал это на этапе компиляции своими средствами
Здравствуйте, varenikAA, Вы писали:
AA>MVVM — для чего используется эта штука? AA>Поводов так извращаться всего 2: AA>1. xaml фигачит дизайнер. модельку кодер. AA>2. представлений несколько.
3. Юнит-тестирование ViewModel гораздо проще, чем гуя целиком.
Ну да. Как бейсик, который они тянули годами и который надо уже просто собраться и ВЫКИНУТЬ!
