Здравствуйте, achmed.

Согласен. Использовать TVF только из-за того, что stored procedures могут вернуть несколько резалтсетов выглядит странно. Если интересно как студия получает схему резалтсета — создайте dataset, запустите визард, что генерит таблицы по выбранным процедурам (add new table... и поехали) и мониторьте sql profiler'ом. Там нет абсолютно никакой магии.

Здравствуйте, Tom, Вы писали:

IT>>Думаешь слаще будет рефакторить сгенерированный код? Легче всего рефакторить код, которого нет.
Tom>Я сгенерированный код не предпологаю рефакторить. План такой, если что то не устраивает в нём — поменять/поправить шаблоны генерации и перегенерить.

Это мы всё проходили. Работает это в разнах сценариях по разному. Например, так. За два часа до релиза находится проблема в сгенерированном коде, править генерилку некогда, поэтому изменения вносятся прямо в сгенерированный код. После релиза и шампанского про эту правку забывают. Другой сценарий, приходит новый человек на проект и начинает править сгенерированный код налево и направо. Через пару недель ему, конечно, надают по рукам, но за это время он понаделает столько, что переделывать хватит ещё на две недели.

Tom>Если быть точнее, я хочу всегад при компиляции генерить DAL. Что бы он всегда был up to date.

Ага, только не забудь про соурс контрол. Не забудь ему и студии объяснить, что каждый девелопер при каждой компиляции будет чекаутить по пол проекта, а потом эти пол проекта сабмитить.

Tom>По поводу кода которого нет — это фикция. Код всегда есть. А в случаях когда его нет ЯВНО — особенна приятна отладка

Зато отладка сгенерированного кода, который есть вдвойне приятна. Отлаживаешь, отлаживаешь, находишь проблему, а исправить не можешь. Хотя почему не можешь? Берешь и правишь, ведь про то, что это сгенерированный код можно забыть, не знать, нет времени на правку генератора.

В общем, ты тетрадочку всё-таки заведи. Весёлые воспоминания я тебе гарантирую

В общем по поводу LLBGenPro первые мнения.

1. К сожалению при генерации враперов для хранимок генерируется не strongly typed result set а DataTable что конечно не устраивает меня. Раз генерировать Linq1Sql или EF умеют генерировать strongly typed result set — то и такой тул как LLBGenpro тоже должен уметь это делаать. Набивать руками тысячи классов для работы с базой — это нереально.

2. нет поддержки работы с entity через хранимки. Не фатальный конечно недостаток. Мелочь, но неприятная.

3. Шаблоны не слишком умные, например я отключил генерация базового класса для entity, сам базовый класс не сгенерировался но в entity осталось наследование от него. Конечно огорчило меня это сильно, шаблоны оказались туповатые, тоесть совсем. Смысла их в текущей реализации конечно немного.

IT>Это мы всё проходили. Работает это в разнах сценариях по разному. Например, так. За два часа до релиза находится проблема в сгенерированном коде, править генерилку некогда, поэтому изменения вносятся прямо в сгенерированный код. После релиза и шампанского про эту правку забывают. Другой сценарий, приходит новый человек на проект и начинает править сгенерированный код налево и направо. Через пару недель ему, конечно, надают по рукам, но за это время он понаделает столько, что переделывать хватит ещё на две недели.
Слушай, есть в проекте есть люди которые делают работу через ж@@пу, то тут ничего не спасёт В моём случае сгенерированные классы править будет просто невозможно. так как билд процесс будет устроен тауим образом, что при каждом билде всё будет генерироваться с нуля. По крайней мере на билд сервере. В общем эта проблема — не наш случай.

Tom>>Если быть точнее, я хочу всегад при компиляции генерить DAL. Что бы он всегда был up to date.
IT>Ага, только не забудь про соурс контрол. Не забудь ему и студии объяснить, что каждый девелопер при каждой компиляции будет чекаутить по пол проекта, а потом эти пол проекта сабмитить.
Ничего не понимаю, с чего вдруг надо чекаутить пол проекта, и тем более пол проекта забирать. Сейчас например у нас много чего генерируется, спокойно, ничего не чекайтится вообще, и тем более не чекинится. Поясни о чём ты.

Tom>>По поводу кода которого нет — это фикция. Код всегда есть. А в случаях когда его нет ЯВНО — особенна приятна отладка

IT>Зато отладка сгенерированного кода, который есть вдвойне приятна. Отлаживаешь, отлаживаешь, находишь проблему, а исправить не можешь. Хотя почему не можешь? Берешь и правишь, ведь про то, что это сгенерированный код можно забыть, не знать, нет времени на правку генератора.
Вот об этом я и писал. Тул который генерирует код должен быть максимально флексибле. Этим меня не устраивает Sql Metal, я никак реально не могу изменить правила по которым она генерит код. Если у тебя нет возможности изменить генерацию — то конечно будут случаи когда придётся править сгенерированный код, что есть полжая ж@@па при сопровождении.

IT>В общем, ты тетрадочку всё-таки заведи. Весёлые воспоминания я тебе гарантирую
Да в общем я тут буду делиться наверное. Вот LLBLGenPro уже отвалился из списка кандидатов ((

PS:
По поводу генерации и BLToolKit, основная проблема с BLToolKit-ом в том, что нет генерилки и я не могу держать постоянно код up to date с базой. Например я описать какой то ad hoc запрос, думаю это возможно при помощи атрибутов. Реально у меня нет шансов провериро его выполнение в compile time. Ну и генерить entity капкой то другой тулзой для BLToolKit-а выглядит по меньшей мере странно. Вот допустим у нас есть 1000 стор, представь как это будет выглядеть, сгенерировать кучук таких классов, в потом ручками описать все вызовы в акцесорах (.

PPS:
Всё что можно сгенерировать автоматически — должно быть сгенерировать автоматически.

Здравствуйте, Tom, Вы писали:

Tom>Слушай, есть в проекте есть люди которые делают работу через ж@@пу, то тут ничего не спасёт

В том то и дело что спасёт Спасает обычно всякое отсутствие возможности сделать что-либо и через ж@@пу и через ж%%пу и даже через жООпу.

Tom>В моём случае сгенерированные классы править будет просто невозможно. так как билд процесс будет устроен тауим образом, что при каждом билде всё будет генерироваться с нуля. По крайней мере на билд сервере. В общем эта проблема — не наш случай.

Конспектируй.

Tom>Ничего не понимаю, с чего вдруг надо чекаутить пол проекта, и тем более пол проекта забирать. Сейчас например у нас много чего генерируется, спокойно, ничего не чекайтится вообще, и тем более не чекинится. Поясни о чём ты.

У тебя сгенерированные файлы будут включены в проект? Будут. Теперь попробуй из студии сделать Submit для проекта с такими файлами.

Tom>Вот об этом я и писал. Тул который генерирует код должен быть максимально флексибле.

Я об этом тоже писал. Максимально флексибле — это код, написанный руками.

Tom>По поводу генерации и BLToolKit, основная проблема с BLToolKit-ом в том, что нет генерилки и я не могу держать постоянно код up to date с базой. Например я описать какой то ad hoc запрос, думаю это возможно при помощи атрибутов. Реально у меня нет шансов провериро его выполнение в compile time. Ну и генерить entity капкой то другой тулзой для BLToolKit-а выглядит по меньшей мере странно. Вот допустим у нас есть 1000 стор, представь как это будет выглядеть, сгенерировать кучук таких классов, в потом ручками описать все вызовы в акцесорах (.

Я никого не принуждаю здесь использовать булкит. Я тебе рассказываю о проблемах precompile-time генерации кода.

Tom>Всё что можно сгенерировать автоматически — должно быть сгенерировать автоматически.

Генерация кода бывает разная. Бывает pre-compile, бывает compile-time, бывает post-compile, бывает run-time. Лучшая из них compile-time. Худшая — pre-compile, как раз та, которую ты выбрал.

Здравствуйте, Holms, Вы писали:

H>Может уже кто создал такую?

Так сядь и напиши Для таблиц там вообще нечего делать — работы на час-полтора, с хранимками сложнее, но тоже решаемо. Зато будет тулза, которая удобна вам и делает именно то, что нужно вам, и именно так, как нужно вам...

Здравствуйте, koandrew, Вы писали:

K>Здравствуйте, Holms, Вы писали:

K>Так сядь и напиши Для таблиц там вообще нечего делать — работы на час-полтора, с хранимками сложнее, но тоже решаемо. Зато будет тулза, которая удобна вам и делает именно то, что нужно вам, и именно так, как нужно вам...
ну ... дык, я всё слежу за этим топиком, может появится умелец

и еще, я не уверен, но есть ли подержка Linq для BLToolkit, а то забивать текст запроса в програму ОЧЕНЬ неохота, так как при этом нету проверки в compile-time изменений в БД.

IT>В том то и дело что спасёт Спасает обычно всякое отсутствие возможности сделать что-либо и через ж@@пу и через ж%%пу и даже через жООпу.
Так я как раз про билд сервер и генерацию всего всегда с нуля как раз и говорил, в этом случае жопы быть не может... Могут быть ошибки компиляции в случае есть код и база не синхронизированы, чего собственно нам и нужно.

Tom>>В моём случае сгенерированные классы править будет просто невозможно. так как билд процесс будет устроен тауим образом, что при каждом билде всё будет генерироваться с нуля. По крайней мере на билд сервере. В общем эта проблема — не наш случай.

IT>Конспектируй.
Ок, уговорил

Tom>>Ничего не понимаю, с чего вдруг надо чекаутить пол проекта, и тем более пол проекта забирать. Сейчас например у нас много чего генерируется, спокойно, ничего не чекайтится вообще, и тем более не чекинится. Поясни о чём ты.
IT>У тебя сгенерированные файлы будут включены в проект? Будут. Теперь попробуй из студии сделать Submit для проекта с такими файлами.
Да ну это не проблема. Во первых можно включить каталог целмком, во вторых можно включить отдельный сгенерированный msbuild файл, в котором уже подключать сгенерированные файлы. Студия сама много чего генерирует, и нормально с этим сгенерированным контентом работает. В общем это не проблема. А если и доставит какие то трудности то они давольно просто должны решаться, уж точно это не show stopper.

IT>Я никого не принуждаю здесь использовать булкит. Я тебе рассказываю о проблемах precompile-time генерации кода.
Я пока реальных проблем не вижу. Давай вспомним то что ты упоминал:
1. Проблемы со студией (отписал мнение выше)
2. Проблемы с тем что кода надо править — может быть проблемой, но в случае тупой генерилки ((.

Что то ещё?

IT>Генерация кода бывает разная. Бывает pre-compile, бывает compile-time, бывает post-compile, бывает run-time. Лучшая из них compile-time. Худшая — pre-compile, как раз та, которую ты выбрал.
Эээ, а почему она худшая, и как это можно поменять? В моём случае ДО компиляции по базе строятся враперы, чем это плохо и как можно сделать лучше? Я вижу один огромный для меня плюс, сгенерированный код всегда будет up to date. Что даёт очень много бенефитов.

Здравствуйте, achmed, Вы писали:

A>Здравствуйте, Flying Dutchman, Вы писали:

FD>>Если же мы сравниваем хранимые процедуры, только возвращающие recordset, с table-valued функциями, то разницы почти никакой. Единственное важное отличие в том, что результат, возвращаемый хранимой процедурой, может быть уже отсортирован.

A>Можно придумать тысячу причин чтобы ограничивать себя использованием функций, только на практике выйдет боком.

Ты меня неправильно понял. Я вовсе не агитирую против использования хранимых процедур в пользу использования табличных функций. Тем более что последние обычно не поддерживаются большинством OR-mapper'ов. Я просто имел в виду, что генератор может более корректно сгенерировать код для представления результата табличной функции, чем для результата хранимой процедуры.

Здравствуйте, Holms, Вы писали:

H>и еще, я не уверен, но есть ли подержка Linq для BLToolkit, а то забивать текст запроса в програму ОЧЕНЬ неохота, так как при этом нету проверки в compile-time изменений в БД.

в процессе, Игорь щас этим усиленно занят
генерация простых запросов есть ужо очень давно (здесь)

Здравствуйте, Tom, Вы писали:

Tom>В общем по поводу LLBGenPro первые мнения.

Tom>1. К сожалению при генерации враперов для хранимок генерируется не strongly typed result set а DataTable что конечно не устраивает меня. Раз генерировать Linq1Sql или EF умеют генерировать strongly typed result set — то и такой тул как LLBGenpro тоже должен уметь это делаать. Набивать руками тысячи классов для работы с базой — это нереально.

Да, это неудобно (хотя я в основном использую для получения данных запросы или представления, а хранимые процедуры использую редко). Я собираюсь связаться по этому поводу с разработчиками LLBLGen, может, они добавят такую возможность.

Tom>2. нет поддержки работы с entity через хранимки. Не фатальный конечно недостаток. Мелочь, но неприятная.

А что такое "Работа с entity через хранимки" и для чего это нужно ?

Tom>3. Шаблоны не слишком умные, например я отключил генерация базового класса для entity, сам базовый класс не сгенерировался но в entity осталось наследование от него. Конечно огорчило меня это сильно, шаблоны оказались туповатые, тоесть совсем. Смысла их в текущей реализации конечно немного.

У LLBLGen есть отдельный дизайнер шаблонов, при помощи которого можно создавать свои шаблоны. Ты его смотрел ? (Сам я с ним никогда не работал, потому что пользовался только стандартными шаблонами и они меня полностью устраивали.)

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, achmed.

S>Согласен. Использовать TVF только из-за того, что stored procedures могут вернуть несколько резалтсетов выглядит странно. Если интересно как студия получает схему резалтсета — создайте dataset, запустите визард, что генерит таблицы по выбранным процедурам (add new table... и поехали) и мониторьте sql profiler'ом. Там нет абсолютно никакой магии.

Скорее всего для этого используется вызов хранимой процедуры в таком виде:

 
set fmtonly on
exec my_proc
set fmtonly off

При этом возвращается только описание resultset (без данных).

Здравствуйте, Tom, Вы писали:

IT>>Я никого не принуждаю здесь использовать булкит. Я тебе рассказываю о проблемах precompile-time генерации кода.
Tom>Я пока реальных проблем не вижу. Давай вспомним то что ты упоминал:
Tom>1. Проблемы со студией (отписал мнение выше)

Проблему ты не понял, ну да она быстро всплывёт.

Tom>2. Проблемы с тем что кода надо править — может быть проблемой, но в случае тупой генерилки ((.

А у тебя будет какая?

IT>>Генерация кода бывает разная. Бывает pre-compile, бывает compile-time, бывает post-compile, бывает run-time. Лучшая из них compile-time. Худшая — pre-compile, как раз та, которую ты выбрал.
Tom>Эээ, а почему она худшая,

Потому что она генерирует императивный код, который можно изменить руками и сильно в этом преуспеть, а потом потерять все изменения даже этого не заметив.

Tom>и как это можно поменять?

Можно попробовать генерировать код, который будет нельзя или бессмысленно менять. Например, если генерировать только декларативные конструкции без императива.

Tom>В моём случае ДО компиляции по базе строятся враперы, чем это плохо и как можно сделать лучше? Я вижу один огромный для меня плюс, сгенерированный код всегда будет up to date. Что даёт очень много бенефитов.

Ты пытаешься решить проблему синхронизации кода с БД и одновременно генерацию кода аксессоров, но тебе на самом деле важнее первое. Второе лишь средство, но средство плохое. Вот над ним нужно поработать и убрать потенциальные проблемы. Повторю проблемы ещё раз.

1. Потенциальная (и главное непредсказуемая) возможность менять императив в сгенерированном коде.
2. Проблемы с соурс-контролом.

Что касается самого генератора, который ты пытаешься найти под себя, то его легче написать самому. На это ушло бы в три раза меньше времени, чем мы тут потраили на трёп и результат был бы такой, какой нужен именно тебе.

FD>Скорее всего для этого используется вызов хранимой процедуры в таком виде:

FD>

 
FD>set fmtonly on
FD>exec my_proc
FD>set fmtonly off
FD>

FD>При этом возвращается только описание resultset (без данных).

на практике это не работает и не используется например linq2sql дизайнером для генерации сущностей

FD>Да, это неудобно (хотя я в основном использую для получения данных запросы или представления, а хранимые процедуры использую редко). Я собираюсь связаться по этому поводу с разработчиками LLBLGen, может, они добавят такую возможность.
Смотри форум, я это обсуждение поднял уже.

Tom>>2. нет поддержки работы с entity через хранимки. Не фатальный конечно недостаток. Мелочь, но неприятная.
FD>А что такое "Работа с entity через хранимки" и для чего это нужно ?
CRUD с использованием хранимок. Нужно для разных целей. Это отдельный разговор.

Tom>>3. Шаблоны не слишком умные, например я отключил генерация базового класса для entity, сам базовый класс не сгенерировался но в entity осталось наследование от него. Конечно огорчило меня это сильно, шаблоны оказались туповатые, тоесть совсем. Смысла их в текущей реализации конечно немного.

FD>У LLBLGen есть отдельный дизайнер шаблонов, при помощи которого можно создавать свои шаблоны. Ты его смотрел ? (Сам я с ним никогда не работал, потому что пользовался только стандартными шаблонами и они меня полностью устраивали.)
Дизайнер не успел ещё посмотреть но не гибкость шаблонов меня уже смутила ((( В принципе я описал свой case. Я пологал что шаблоны сделаны на основе модификации AST. А они на порядок тупее ((((

IT>Проблему ты не понял, ну да она быстро всплывёт.
Ну дык обрисуй если я не понял

Tom>>2. Проблемы с тем что кода надо править — может быть проблемой, но в случае тупой генерилки ((.
IT>А у тебя будет какая?
Дык я же вумную ищу

IT>>>Генерация кода бывает разная. Бывает pre-compile, бывает compile-time, бывает post-compile, бывает run-time. Лучшая из них compile-time. Худшая — pre-compile, как раз та, которую ты выбрал.
Tom>>Эээ, а почему она худшая,
IT>Потому что она генерирует императивный код, который можно изменить руками и сильно в этом преуспеть, а потом потерять все изменения даже этого не заметив.
Игорь, мы не будем менять сгенерированный код, и даже в SCM его класть не будем

Tom>>и как это можно поменять?
IT>Можно попробовать генерировать код, который будет нельзя или бессмысленно менять. Например, если генерировать только декларативные конструкции без императива.
А, ну теперь ход мыслей понятен

Tom>>В моём случае ДО компиляции по базе строятся враперы, чем это плохо и как можно сделать лучше? Я вижу один огромный для меня плюс, сгенерированный код всегда будет up to date. Что даёт очень много бенефитов.

IT>Ты пытаешься решить проблему синхронизации кода с БД и одновременно генерацию кода аксессоров, но тебе на самом деле важнее первое. Второе лишь средство, но средство плохое. Вот над ним нужно поработать и убрать потенциальные проблемы. Повторю проблемы ещё раз.

IT>1. Потенциальная (и главное непредсказуемая) возможность менять императив в сгенерированном коде.
Как писал выше — отпадает. Руками абсолютно точно никто ничего менять не будет.

IT>2. Проблемы с соурс-контролом.
Так и не понят какие.

IT>Что касается самого генератора, который ты пытаешься найти под себя, то его легче написать самому. На это ушло бы в три раза меньше времени, чем мы тут потраили на трёп и результат был бы такой, какой нужен именно тебе.
Чукча постарел, обзавёлса жирком на бочках и уже давно не учавствует в велосипедных гонках. Да и есть у меня сомнения в том что оно можно быстро написать. Да и зачем если есть уже готовые решения.

Здравствуйте, Tom, Вы писали:

IT>>Потому что она генерирует императивный код, который можно изменить руками и сильно в этом преуспеть, а потом потерять все изменения даже этого не заметив.
Tom>Игорь, мы не будем менять сгенерированный код, и даже в SCM его класть не будем

Это ты не будешь его никуда класть, а студия будет ещё как. Попробуй ради эксперимента.

IT>>1. Потенциальная (и главное непредсказуемая) возможность менять императив в сгенерированном коде.
Tom>Как писал выше — отпадает. Руками абсолютно точно никто ничего менять не будет.

Заведи для этого отдельную тетрадку

IT>>2. Проблемы с соурс-контролом.
Tom>Так и не понят какие.

Поэкспериментируй и поймёшь.

IT>>Что касается самого генератора, который ты пытаешься найти под себя, то его легче написать самому. На это ушло бы в три раза меньше времени, чем мы тут потраили на трёп и результат был бы такой, какой нужен именно тебе.
Tom>Чукча постарел, обзавёлса жирком на бочках и уже давно не учавствует в велосипедных гонках. Да и есть у меня сомнения в том что оно можно быстро написать. Да и зачем если есть уже готовые решения.

А сомнений в том, что ты найдёшь не совсем то, что тебе нужно у тебя нет? Да и на настройку стандартного велосипеда у тебя уйдёт не меньше времени, чем на написание своего собственного.

Здравствуйте, Flying Dutchman.

FD>Скорее всего для этого используется вызов хранимой процедуры в таком виде:

Ага, забыл что именно дёргается просто.

Интереснопочему никто не предложил студийные шаблоны T4?
http://andir-notes.blogspot.com/2009/02/t4-visual-studio.html

IT>А сомнений в том, что ты найдёшь не совсем то, что тебе нужно у тебя нет? Да и на настройку стандартного велосипеда у тебя уйдёт не меньше времени, чем на написание своего собственного.
http://andir-notes.blogspot.com/2009/02/t4-visual-studio.html

Ы?