Здравствуйте, VladD2, Вы писали:
IT>>Автосвойства полезны как раз для того, чтобы лишний раз в такой код не заходить. Маппинг на поля, как я понимаю, вообще не возможен.
VD>Ээээ... Товарисч, не пристало вам такую пургу нести! В мсиле автосвойств нет как ложки в матрице. Эффекта "незахождения отладчика в свойство" компилятор шарпа добивается путем добавления к коду свойств атрибутов System.Runtime.CompilerServices.CompilerGeneratedAttribute. Того же эффекта можно достичь добавив атрибут System.Diagnostics.DebuggerNonUserCode.
Товарисч, вам бы спуститься с небес на ... Нет, точнее выйти из сумрака низкоуровневого кода и атрибутов компилятора в обычный мир. После этого можно будет написать код с использованием автосвойств и попробовать войти в него отладчиком.
Кстати, не уверен, что CompilerGeneratedAttribute приводит к игнорирования кода отладчиком. Хотя всё может быть. Тем не менее самому отладчику глубоко плевать как на CompilerGeneratedAttribute, так и на DebuggerNonUserCode вместе с DebuggerStepThrough. Отладчик ходит по тому коду, по которому ему сказал ходить компилятор, не больше и не меньше.
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: [ANN] Надстройка к студии для генерации классов к Lin
Здравствуйте, VladD2, Вы писали:
VD>Сдается мне лучше вообще не использовать CodeDom.
VD>Можно попробовать заменить CodeDom на CCI AST. VD>Но еще лучше просто генерировать текст. Например, тем же T4.
VD>CodeDom обижен природой. Тут уже ничего не поделаешь.
Ну фиг его знает. Я стал его использовать в основном для того, чтобы облегчить переход на другие языки (для N уже есть провайдер? )...
VD>В качестве затычки можешь просто использовать CodeSnippetXxx для подстановки текста в нужное место.
Здравствуйте, VladD2, Вы писали:
VD>Ты ошибся только в двух предположениях. Она не готовая и не вполне вменяемая.
Мой опыт свидетельствует об обратном. А тот факт, что не любой код можно взаимно однозначно отобразить на CodeDom-модель, если подумать, следует из языковой независимости данной модели. Тем не менее, работать с ней довольно удобно. И уж точно она уже готовая и уже работает
Не факт, что изобретение своей модели является лучшим решением (что-то мне подсказывает, что в итоге выйдет нечто подобное CodeDom'у). Можно конечно соорудить некий языково-независимый DSL (CodeDom — это тоже DSL, но он увиверсален), для которого потом понаписать трансляторы в нужные целевые языки, тогда, возможно, удастся заимплементить всё необходимое в нём (в т.ч. и автосвойста), но, как это обычно бывает, это только вопрос времени, когда мы упрёмся в ограничения, вызванные специализацией. Всё-таки я верю, что CodeDom дизайнили товарищи с опытом побольше моего, и шанс нарваться на что-то нереализуемое там меньше...
Далее, тут есть ещё одна проблема. Дело в том, что понятие "красивый код" субъективно по определению, и потому я опасаюсь потока фидбека а-ля "сделайте скобочку на предудущей/следующей строке", "используйте пробелы/табы для форматирования" и тому подобную ерунду, которую гораздо проще сделать с помощью решарпера или ещё какого-нить средства форматирования кода. У меня есть мысль задействовать R# при его наличии для пост-процессинга снегерённого кода, но то, что предложили
разработчики, мне кажется чрезмерно замороченным...
Хотя, конечно, я могу быть не прав. Если объём предложений об отказе от CodeDom будет продолжать поступать — ну чтож, переделаю. Благо я являюсь сторонником SRP и кодогенерация чётко отделена от остальных частей, а потому может быть независимо переписана.
Здравствуйте, IT, Вы писали:
IT>Кстати, не уверен, что CompilerGeneratedAttribute приводит к игнорирования кода отладчиком. Хотя всё может быть. Тем не менее самому отладчику глубоко плевать как на CompilerGeneratedAttribute, так и на DebuggerNonUserCode вместе с DebuggerStepThrough. Отладчик ходит по тому коду, по которому ему сказал ходить компилятор, не больше и не меньше.
Уверен? Что-то я не помню, чтобы в немерле была спец-обработка по поводу DebuggerNonUserCode, вроде как он работает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [ANN] Надстройка к студии для генерации классов к Lin
Здравствуйте, koandrew, Вы писали:
K>Ну фиг его знает. Я стал его использовать в основном для того, чтобы облегчить переход на другие языки (для N уже есть провайдер? )...
Есть. Но на мой взгляд здесь текстовый T4 был бы более подходящим решением.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: [ANN] Надстройка к студии для генерации классов к Lin
Здравствуйте, koandrew, Вы писали:
K>Всё-таки я верю, что CodeDom дизайнили товарищи с опытом побольше моего, и шанс нарваться на что-то нереализуемое там меньше...
Не КодДом проектировали какие-то индусы под сериализатор в ВинФормсах. От того он и такой недоделанный.
То что он абстрагирован от языка (т.е. является AST в полном смысле этого слов) — это да. Но все же он дико не удобен и не гибок.
K>Далее, тут есть ещё одна проблема. Дело в том, что понятие "красивый код" субъективно по определению, и потому я опасаюсь потока фидбека а-ля "сделайте скобочку на предудущей/следующей строке", "используйте пробелы/табы для форматирования" и тому подобную ерунду, которую гораздо проще сделать с помощью решарпера или ещё какого-нить средства форматирования кода. У меня есть мысль задействовать R# при его наличии для пост-процессинга снегерённого кода, но то, что предложили
разработчики, мне кажется чрезмерно замороченным...
Кстати, не стоит называть РеШарпер R#. У нас есть свой R#.
Что по поводу форматирования, то это как раз не так важно. А вот то что за код будет генерировать — это важно. И тут текстовый генератор был бы более удобен, по моему.
K>Хотя, конечно, я могу быть не прав. Если объём предложений об отказе от CodeDom будет продолжать поступать — ну чтож, переделаю. Благо я являюсь сторонником SRP и кодогенерация чётко отделена от остальных частей, а потому может быть независимо переписана.
Если не откажешься от самого КодДома, то возмоно лучше взять его аналог из CCI. Он вроде как совместим с КодДомом но расширен для удобства применения. Для него имеется генерация форматированного кода на шарпе и васике (если не ошибаюсь).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: [ANN] Надстройка к студии для генерации классов к Lin
Здравствуйте, VladD2, Вы писали:
VD>Уверен? Что-то я не помню, чтобы в немерле была спец-обработка по поводу DebuggerNonUserCode, вроде как он работает.
Да, мои сведения говорят о том же. Этим делом рулит галка Debug Non-User Code иил что-то вроде того в настройках. Методы, помеченные DebuggerStepThroughAttribute, дебаггер проскакивает, если только не установить бряк внутри (вроде). В принципе, могу добавить навешивание этого атрибута к сгенерённый код — делов-то на минуту...
Здравствуйте, VladD2, Вы писали:
VD>Не КодДом проектировали какие-то индусы под сериализатор в ВинФормсах. От того он и такой недоделанный. VD>То что он абстрагирован от языка (т.е. является AST в полном смысле этого слов) — это да. Но все же он дико не удобен и не гибок.
Может и так — не знаю
VD>Кстати, не стоит называть РеШарпер R#. У нас есть свой R#.
VD>Что по поводу форматирования, то это как раз не так важно. А вот то что за код будет генерировать — это важно. И тут текстовый генератор был бы более удобен, по моему.
Я очень опасаюсь того, что юзеры начнут наезжать на тему codestyle и править шаблоны руками. Тогда придётся в инсталлере этот момент как-то обрабатывать, а как — я пока понятия не имею...
VD>Если не откажешься от самого КодДома, то возмоно лучше взять его аналог из CCI. Он вроде как совместим с КодДомом но расширен для удобства применения. Для него имеется генерация форматированного кода на шарпе и васике (если не ошибаюсь).
А вот за это спасибо, посмотрю...
Здравствуйте, VladD2, Вы писали:
VD>Есть. Но на мой взгляд здесь текстовый T4 был бы более подходящим решением.
Как я уже сказал выше, надо будет придумать, как разруливать ручные модификации этих шаблонов при обновлении. Ну и какой-то простой AST Model надо будет сварганить поверх этого дела — чтобы сохранить языковую независимость..
Здравствуйте, VladD2, Вы писали:
IT>>Кстати, не уверен, что CompilerGeneratedAttribute приводит к игнорирования кода отладчиком. Хотя всё может быть. Тем не менее самому отладчику глубоко плевать как на CompilerGeneratedAttribute, так и на DebuggerNonUserCode вместе с DebuggerStepThrough. Отладчик ходит по тому коду, по которому ему сказал ходить компилятор, не больше и не меньше.
VD>Уверен? Что-то я не помню, чтобы в немерле была спец-обработка по поводу DebuggerNonUserCode, вроде как он работает.
Она может быть в емите.
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: [ANN] Надстройка к студии для генерации классов к Lin
Здравствуйте, koandrew, Вы писали:
K>Как я уже сказал выше, надо будет придумать, как разруливать ручные модификации этих шаблонов при обновлении.
Не надо это разруливать. Помечай файлы как read-only и тот кто их поправит будет сам себе злобный буратина.
K>Ну и какой-то простой AST Model надо будет сварганить поверх этого дела — чтобы сохранить языковую независимость..
Это, да.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: [ANN] Надстройка к студии для генерации классов к Li
Dog>>Хоть можно будет шаблоны править по ходу. VD>Ну, вот это будет вызвать проблемы. Ты же их будешь локально править. Если потом и автор их поправит, то будет тебе работа по синхронизации. При некотором количестве различий проще будет твои правки выбросить. Значит надо добавить возможность использовать свои шаблоны. Можно скопировать стандартный, поправить и указать какой использовтаь. Т4 хоть легко читать и править можно.
Re[9]: [ANN] Надстройка к студии для генерации классов к Lin
VD>>Что по поводу форматирования, то это как раз не так важно. А вот то что за код будет генерировать — это важно. И тут текстовый генератор был бы более удобен, по моему. K>Я очень опасаюсь того, что юзеры начнут наезжать на тему codestyle и править шаблоны руками.
И это правильно
K> Тогда придётся в инсталлере этот момент как-то обрабатывать, а как — я пока понятия не имею...
А можно добавить в конфиг какой шаблон используется ?
Re: [ANN] Надстройка к студии для генерации классов к Linq2B
K>Краткая инструкция по использованию: K>Правый щелчок на c# проекте -> Add New Item... -> BLToolkit Settings File -> Назови его как-нить(это имя будет частью имени контекста — SomethingDbContext) -> OK
что то не могу найти этот файл (BLToolkit Settings File), когда создаю web site
Re[2]: [ANN] Надстройка к студии для генерации классов к Lin
Здравствуйте, kkolyan33, Вы писали:
K>что то не могу найти этот файл (BLToolkit Settings File), когда создаю web site
Этот пункт доступен только для C# Library проектов и Console Application. Ибо мне кажется неправильным пихать DAL в presentation layer. Но "если очень хочется", то есть способ — правый клик на проекте -> Add database definition, затем переименовать файл как вам нужно. Дальше всё как обычно...
Здравствуйте, koandrew, Вы писали:
K>Этот пункт доступен только для C# Library проектов и Console Application. Ибо мне кажется неправильным пихать DAL в presentation layer.
Думаю, стоит ослабить это ограничение, не путай layer и tier — зачастую несколько layer'ов вполне себе нормально сосуществуют в пределах одного проекта.
Re[3]: [ANN] Надстройка к студии для генерации классов к Lin
Здравствуйте, koandrew, Вы писали:
K>>что то не могу найти этот файл (BLToolkit Settings File), когда создаю web site K>Этот пункт доступен только для C# Library проектов и Console Application. Ибо мне кажется неправильным пихать DAL в presentation layer.
Их всё равно больше.
Если нам не помогут, то мы тоже никого не пощадим.
Re: [ANN] Надстройка к студии для генерации классов к Linq2B
Если нам не помогут, то мы тоже никого не пощадим.
)...
Значит надо добавить возможность использовать свои шаблоны. Можно скопировать стандартный, поправить и указать какой использовтаь. Т4 хоть легко читать и править можно.
