Здравствуйте, Aquilaware, Вы писали:
A>Это вы зря. Надежная штука, работает хорошо и везде. В VS 2017 вообще из коробки идет в конфигурации по-умолчанию.
Здравствуйте, VladD2, Вы писали:
VD>Кодогенерация тоже разная бывает. Так что ты все же опиши саму задачу. Может мы тебе что-то более дельное подскажем.
Есть удалённая база данных к которой нужно выполнять параметризованные запросы, модифицируя их как на стороне клиента, так и на стороне сервера.
Всё на велосипедах. Сторонние решения, нормальные ORM, LINQ/IQuerable и т.д. не подходят из-за проблем с лицензированием, сертификацией, внутренней политикой или моральными ограничениями. Ну и чем тут поможешь, кроме смены места работы?
Здравствуйте, LWhisper, Вы писали:
LW>Есть удалённая база данных к которой нужно выполнять параметризованные запросы, модифицируя их как на стороне клиента, так и на стороне сервера. LW>Всё на велосипедах. Сторонние решения, нормальные ORM, LINQ/IQuerable и т.д. не подходят из-за проблем с лицензированием, сертификацией, внутренней политикой или моральными ограничениями. Ну и чем тут поможешь, кроме смены места работы?
А какие проблемы с лецензированием могут быть у LINQ?
Собственно я бы, в твоем случае, как раз и посоветовал бы использовать LINQ + генерацию кода на базе деревьев выражений (ET). Создаешь сборку через рефлексию (DefineDynamicAssembly/DefineDynamicModule/DefineType/DefineMethod) и используешь метод CompileToMethod у ET. Далее читаешь метаданные БД и генерируешь нужные методы.
Т4 тут тоже подошел бы.
Если не страшно задействовать Nemerle, то это вообще идеальное решение для подобных задач. Вот очень похожий пример.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Собственно я бы, в твоем случае, как раз и посоветовал бы использовать LINQ + генерацию кода на базе деревьев выражений (ET). Создаешь сборку через рефлексию (DefineDynamicAssembly/DefineDynamicModule/DefineType/DefineMethod) и используешь метод CompileToMethod у ET. Далее читаешь метаданные БД и генерируешь нужные методы.
VD>Т4 тут тоже подошел бы.
VD>Если не страшно задействовать Nemerle, то это вообще идеальное решение для подобных задач. Вот очень похожий пример.
И, как я описал, ничто из этого не подходит.
Я бы тоже взял за основу LINQ. Увы. (
Что касается T4, ни из примеров, ни из документации, я так и не смог понять — как его можно использовать в ситуациях отличных от "мне нужно 180 методов Sum, для (U)Int8/16/32/64 и их комбинаций". Я хочу только объявить метод в интерфейсе и получить кучу готового кода.
S>А вот это прям идеальный сценарий для Roslyn analyser-a. Или расширения какого. Решарпер из коробки могёт.
Вот в поисках подобных решений я и нахожусь. Решарпер, к сожалению, расширяется только через систему плагинов, которые развёртываются через NuGet-пакеты, а ссылки на SDK вчера были битые. :D
Здравствуйте, VladD2, Вы писали:
VD>Дык чем не подходит то? Какие-то странные у тебя там пробемы.
Ну, вот представь, что ты разрабатываешь ядро Linux, и вдруг говоришь — а давайте заюзаем MSSQL!
Чем не подходит? Ну вот, несовместимо с жизнью. Я же сказал, что бессмысленно искать альтернативы. Есть один путь, которым можно пойти сейчас. Другие пока закрыты.
Здравствуйте, Sinix, Вы писали: LW>>Народ вроде что-то на Razor ваял от безысходности.
Я из этого народа. Пишу на Razor шаблоны для генерации модели + контроллера + пачки CRUD-вьюшек для ASP.NET сайта по информации из набиваемого руками XML файла.
В солюшне имею отдельный консольный проект генератора.
Добавляю в него новый XML файл модели, набиваю руками список полей
Из консоли вызываю CodeGen.exe Model <имя XML>
Razor компилирует шаблоны, кладёт файлы в нужные папки, добавляет эти файлы в проекты студии через
var targetProject = new Microsoft.Build.Evaluation.Project("targetProj.csproj");
if (!targetProject.Items.Any(i => i.ItemType == "Compile" && i.UnevaluatedInclude == relPath))
targetProject.AddItem("Compile", relPath);
// relPath - относительный путь к файлу от корня проекта
Альтабаюсь обратно в студию, она предлагает перезагрузить изменившийся csproj, соглашаюсь.
Получаю новые файлы. Это что касается генерации новых файлов, вопрос редактирования имеющихся пока открытый.
По ощущениям: не нравится.
Хотел получить такое же удобства с Intellisense как при редактировании ASP.NET шаблонов,
на деле Razor'ские шаблоны испещрены руганью на старую версию .NET и отсутствие ссылок на неймспейсы.
(со включённым решарпером ругани ещё больше)
Скрытый текст
Причём большая часть ошибок лживые — тот же вывод типов через var прекрасно работает, но часть настоящие, например не работает $-интерполяция строк. Всё это раздражает, но настроить пока не удаётся. Народ также мучается.
Здравствуйте, D.Lans, Вы писали:
LW>>>Народ вроде что-то на Razor ваял от безысходности. DL>Я из этого народа. Пишу на Razor шаблоны для генерации модели + контроллера + пачки CRUD-вьюшек для ASP.NET сайта по информации из набиваемого руками XML файла.
Знаком я был с командой, которая примерно так и делала. Только это было задолго до Razor, генератор по XML был просто на C# написан.
И, кстати, они ещё и юнит-тесты генерировали.
По отзывам — очень неудобная система. Экономия времени по сравнению с на написанием этого комплекта руками небольшая, и, к тому же, разовая.
А вот поддержка всего этого превращается в кошмар: всё автогенерённое, поэтому если нужно изменить поведение в какой-то части, то нужно или править генератор (что долго и рискованно и очень неудобно при совместной работе) или делать какие-то ручные шаги после генерации.
Так что там постоянно были какие-то баги из-за того, что что-то не так сгенерировалось или кто-то забыл что-то запустить или исправить.
К сожалению, у них был неуправляемый техлид-энтузиаст и неопытный ПМ, поэтому команда так и мучалась пока худо-бедно не вышли в продакшн, после чего проект прикрыли.
По слухам прикрыли из-за очень большого времени добавления новых фич (ещё бы, попроавить генератор, проверить все места, где что-то генерировалось...)
Возможно это из-за того, что они "не умели готовить" генерацию.
Но отношение у меня к ней с тех пор настороженное. Ну, то есть, сам-то применяю, но просчитывая все последствия.
Здравствуйте, LWhisper, Вы писали:
LW>Ну, вот представь, что ты разрабатываешь ядро Linux, и вдруг говоришь — а давайте заюзаем MSSQL!
Ну, а зачем не относящиеся к делу вещи то приплетать? Ты на дотнете пишешь? Раз так то что тебе мешает использовать всего его средства?
LW>Чем не подходит? Ну вот, несовместимо с жизнью.
Чем? Аргументы то есть какие-то? Или "строгли белив"(ц) ?
LW>Я же сказал, что бессмысленно искать альтернативы. Есть один путь, которым можно пойти сейчас. Другие пока закрыты.
По-моему какая-то бессмысленная тема. Ты не определился с критериями и непонятно что хочешь.
Первое правил, если хочешь найти ответ на вопрос — определи четкие критерии. Отвергаешь что-то? Напиши список аргументов против этого чего-то. Потом сравни полученные списки. Список достоинств тоже не помешает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, LWhisper, Вы писали:
LW>По мере написания кода. В идеале, из менюшки по Alt+Enter, к сожалению, функционала live-template не хватает. ((
Чего именно не хватает? Многофайловых?
LW>Думаю в этом направлении, но чёрт возьми, мне не нравится способ паблишенга плагинов к R#, не говоря уже о том, что настройка окружения — это какой-то кромешный ад, а темплейты они до сих пор не запилили (или что-то изменилось?).
А можно подробнее про ад и незапиленные темплейты?
LW>Перезагрузка проектов не устраивает. Плюс придётся вручную добавлять интеграцию с CVS (хотя бы на уровне автоматического чекаута файлов).
Если использовать wildcard-ы, и генерировать файлы в соотвествющие места, то можно обойтись без перегрузки.
Здравствуйте, LWhisper, Вы писали:
LW>Есть удалённая база данных к которой нужно выполнять параметризованные запросы, модифицируя их как на стороне клиента, так и на стороне сервера. LW>Всё на велосипедах. Сторонние решения, нормальные ORM, LINQ/IQuerable и т.д. не подходят из-за проблем с лицензированием, сертификацией, внутренней политикой или моральными ограничениями. Ну и чем тут поможешь, кроме смены места работы?
Или страдать, или никак. Ещё можно посмотреть генерацию моделей на t4 в linq2db. https://github.com/linq2db/t4models
Здравствуйте, qxWork, Вы писали:
W>Чего именно не хватает? Многофайловых?
По сигнатуре вызова несуществующего метода, нужно вывести типы N аргументов и сгенерировать несколько типов и методов, пусть даже в том же самом файле. Насколько я понимаю, этого можно добиться, используя расширения для темплейтов, но их, опять же, нужно писать.
W>А можно подробнее про ад и незапиленные темплейты?
Конечно. Открываем доки. Радуемся простоте решения.
Проходим по ссылке и выпадаем в осадок, так как приходит осознание того, что нам предлагают решить загадку Эйнштейна. В дальнейшем это подозрение только крепнет. Но хорошо, мы взрослые матёрые программисты, умеем в мануалы и выполнять пошаговые инструкции.
Вводим: PM> Install-Package JetBrains.ReSharper.SDK -Version 2017.2.1
Получаем: Install-Package : Unable to find version '2017.2.1' of package 'JetBrains.ReSharper.SDK'.
Вот это поворот!
Ладно, с кем не бывает. Лезем на сайт за стэндалон версией SDK...
404 Not Found (в настоящий момент исправлено, я везучий)
Стянув пакет локально, пытаемся установить.
Attempting to resolve dependency 'xunit.abstractions (= 2.0.1)'.
The 'xunit.abstractions 2.0.1' package requires NuGet client version '2.12' or above, but the current NuGet version is '2.8.60610.756'.
Да ну растудыж твою тудыж!
Окей, сам виноват, ставим свежие обновления. Повторяем операцию.
Установилось! Ура! Ну, теперь то мы напишем свой первый плагин и заживём!..
Стоп. Что за .nuspec? Я просто хочу нажать F5 и увидеть Hello world в менюшке R#!
Гиперссылок нет. Поиск по документации, естественно, результатов не даёт (это ж поиск!).
Окей, мы матёрые программисты и умеем пользоваться гуглом.
Попытка номер два. Хм. Кажется, это то, что мне нужно. Но стоп, а что я читал до этого? Чм экстеншены отличаются от плагинов? И если это разные штуки, то где описание .nuspec для экстеншенов?! Что происходит?!
И всё это время в голове крутится мысль, что уж лет пять назад были шаблоны проектов, в которые можно воткнуть всё, включая зависимости от NuGet-пакетов, так какого же дьявола приходится делать все это руками?!
Здравствуйте, LWhisper, Вы писали:
LW>Юзер пишет: LW>
LW>IInterface nt = new MyType();
LW>nt.DoSomething(arg1, arg2, arg3);
LW>
LW>Нажимает хоткей, генериурется метод с нужной сигнатурой на основе переданных аргументов в IInterface, и его реализации во всех известных наследниках данного интерфейса.
Alt+Enter создает метод в интерфейсе. Еще один Alt+Enter на созданном методе создаст реализации во всех типах.
Если хочется создать непустую реализацию, можно ее написать в теле интерфейса и оттуда Alt+Enter-ом же размножить по типам.
Здравствуйте, VladD2, Вы писали:
VD>Первое правил, если хочешь найти ответ на вопрос — определи четкие критерии. Отвергаешь что-то? Напиши список аргументов против этого чего-то. Потом сравни полученные списки. Список достоинств тоже не помешает.
Влад, ты пытаешься ответить на вопрос "как это сделать правильно", который я не задавал. Я прекрасно знаю, как это сделать по-человечески.
Я же спрашиваю, "как реализовать конкретно вот эту штуку". Я могу навертеть что угодно над и под описанным решением, но это единственный возможный вариант. Аргументов нет и не будет, поскольку все контраргумнты разобьются о железобетонное "но я хочу так". Я надеюсь, что в будущем мне удастся уйти от этого дерьмового решения, но сейчас это не возможно. Разве что "для души", но нужно "для дела".
Здравствуйте, qxWork, Вы писали:
W>Если хочется создать непустую реализацию, можно ее написать в теле интерфейса и оттуда Alt+Enter-ом же размножить по типам.
Я думал о подобном подходе, довольно малой кровью даже удастся убрать все зависимости и сделать единый интерфейс доступа, но, к сожалению, это никак не избавит от необходимости создать класс, описывающий аргументы вызываемого метода и возвращаемый результат. Всё необходимое можно вывести из сигнатуры метода и переданных аргументов, но их сперва нужно распарсить, тобишь перехватить обработчик того самого ALt+Enter'а.
Здравствуйте, LWhisper, Вы писали:
LW>Я думал о подобном подходе, довольно малой кровью даже удастся убрать все зависимости и сделать единый интерфейс доступа, но, к сожалению, это никак не избавит от необходимости создать класс, описывающий аргументы вызываемого метода и возвращаемый результат. Всё необходимое можно вывести из сигнатуры метода и переданных аргументов, но их сперва нужно распарсить, тобишь перехватить обработчик того самого ALt+Enter'а.
Что-то я перестал понимать. Предыдущий кусок кода с вызовом метода и его аргументами откуда взялся?
(
