IT>Я не использую его в коммерческих проектах. К сожалению, у меня в банке очень жёсткое полиси на весь софт. Средства разработки тоже ограничены, например, из дистрибутива студии вакинут даже VB. Но как только выйдет релиз 1.0 я попытаюсь зареквестить Немерлю хотя бы для оценки возможностей. А там кто знает, может и в продакшин протащу когда-нибудь. В общем, это не просто моё желание или нежелание, это борьба с бюрократической машиной, в которой (в борьбе) ошибок быть не должно.
Пошёл полкупать соль и спички. Новый банковский кризих похоже будет относительно скоро
Здравствуйте, Tom, Вы писали:
IT>>Я не использую его в коммерческих проектах. К сожалению, у меня в банке очень жёсткое полиси на весь софт. Средства разработки тоже ограничены, например, из дистрибутива студии вакинут даже VB. Но как только выйдет релиз 1.0 я попытаюсь зареквестить Немерлю хотя бы для оценки возможностей. А там кто знает, может и в продакшин протащу когда-нибудь. В общем, это не просто моё желание или нежелание, это борьба с бюрократической машиной, в которой (в борьбе) ошибок быть не должно.
Tom>Пошёл полкупать соль и спички. Новый банковский кризих похоже будет относительно скоро
Всё как раз наоборот. Если бы я использовал в банках не BLToolkit, а как ты хочешь precompile генерацию кода, то тебе уже давно не на что было бы покупать соль и спички. А если бы я использовал Немерле, то и кризиса не было бы.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Tom, Вы писали:
IT>>>Я не использую его в коммерческих проектах. К сожалению, у меня в банке очень жёсткое полиси на весь софт. Средства разработки тоже ограничены, например, из дистрибутива студии вакинут даже VB. Но как только выйдет релиз 1.0 я попытаюсь зареквестить Немерлю хотя бы для оценки возможностей. А там кто знает, может и в продакшин протащу когда-нибудь. В общем, это не просто моё желание или нежелание, это борьба с бюрократической машиной, в которой (в борьбе) ошибок быть не должно.
Tom>>Пошёл полкупать соль и спички. Новый банковский кризих похоже будет относительно скоро
IT>Всё как раз наоборот. Если бы я использовал в банках не BLToolkit, а как ты хочешь precompile генерацию кода, то тебе уже давно не на что было бы покупать соль и спички. А если бы я использовал Немерле, то и кризиса не было бы.
Игорь, разницы в моём подходе, с генерацией кода во время билда и в рантайме нет. BLToolkit, делает это в рантайме.
Разница ещё в том что акцесоры я генерирую, а у тебя надо руками писать.
Так что я пока твоих непониваю аргументов. Вон тот же EF/Linq2Sql генерируют себе энтити в компайлтайм или даже дизайнтайм и ничего.
Здравствуйте, Tom, Вы писали:
Tom>Игорь, разницы в моём подходе, с генерацией кода во время билда и в рантайме нет.
Разница есть. BLToolkit генерирует исполняемый код, а твои генераторы мусор.
Tom>Так что я пока твоих непониваю аргументов. Вон тот же EF/Linq2Sql генерируют себе энтити в компайлтайм или даже дизайнтайм и ничего.
В компайл тайм они ничего не генерируют. Они точно так же генерируют мусор, если угодно исходный мусор, по аналогии с исходым кодом.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Tom, Вы писали:
Tom>>Игорь, разницы в моём подходе, с генерацией кода во время билда и в рантайме нет.
IT>Разница есть. BLToolkit генерирует исполняемый код, а твои генераторы мусор.
Tom>>Так что я пока твоих непониваю аргументов. Вон тот же EF/Linq2Sql генерируют себе энтити в компайлтайм или даже дизайнтайм и ничего.
IT>В компайл тайм они ничего не генерируют. Они точно так же генерируют мусор, если угодно исходный мусор, по аналогии с исходым кодом.
Видимо я тебя не понимаю. Без конкретных примеров мы к пониманию не прийдём. Их есть у тебя? Я могу свою идею пояснить.
Я предпологаю, что TSQL код у нас будет отделён от C# кода.
Тоесть в тесте писать запросы мы не будем РУКАМИ.
Но, C# враперы над TSQL запросами будут всё же строится динамически в рантайме.
Как это будет.
Допустим у нас есть каталог SQL где лежат файлы, в каждом из них для простоты допустиь ad hoc запрос, а не хранимка.
Во compile time мы будем выполнять их используь FMTONLY и получать метаданные о resultset-е.
По ним мы будем строить соответствующий класс для resultset-а и функцию для выполнения данного ad hoc запроса.
Естественно что в сгенерированном коде будет присуствовать само тело запроса поднятое из файла.
Практически аналогично и с хранимками, разница лиш в том что там к метаданным ещё параметры добавляются.
Зачем нужно хранить TSQL отдельно от кода — в первую очередь что бы иметь нормальную возможность провалидировать этот TSQL и рефакторить его отдельно от кода.
Например при помощи той же VSTS Database Edition GDR.
Можешь на примерах как то описать принципиальные ошибки в таком подходе?
Здравствуйте, Tom, Вы писали:
Tom>Я предпологаю, что TSQL код у нас будет отделён от C# кода. Tom>Тоесть в тесте писать запросы мы не будем РУКАМИ. Tom>Но, C# враперы над TSQL запросами будут всё же строится динамически в рантайме. Tom>Как это будет.
Tom>Допустим у нас есть каталог SQL где лежат файлы, в каждом из них для простоты допустиь ad hoc запрос, а не хранимка. Tom>Во compile time мы будем выполнять их используь FMTONLY и получать метаданные о resultset-е. Tom>По ним мы будем строить соответствующий класс для resultset-а и функцию для выполнения данного ad hoc запроса. Tom>Естественно что в сгенерированном коде будет присуствовать само тело запроса поднятое из файла.
Tom>Зачем нужно хранить TSQL отдельно от кода — в первую очередь что бы иметь нормальную возможность провалидировать этот TSQL и рефакторить его отдельно от кода. Tom>Например при помощи той же VSTS Database Edition GDR.
Tom>Можешь на примерах как то описать принципиальные ошибки в таком подходе?
Начнём с того, что всё это элементарно не имеет никакого смысла. Самое сложное в DAL — это рутина ручной набивки аксессоров, которая хоть так хоть эдак уходит. После этого при разработке, например, какой-нибудь формы или отчёта, на разработку SQL запроса уходит два часа, на DAL и BL пять минут, а на UI неделя. Ну давай добавим ещё две минуты на твой ad hoc класс. На неделю UI это всё равно никак не повлияет. Не там ты оптимизируешь.
Но допустим вы нагенерировали кучу ad hoc классов. Сразу возникает несколько вопросов.
1. Для запросов SELECT * FROM Person и SELECT * FROM Person WHERE ID = 1 у тебя будет генерироваться один класс или два?
2. Как ты собираешься задавать имена своим классам?
3. Все свои классы ты будешь хранить в одном namespace или в разных? Как это задавать?
4. Готов ли ты к тому, что основная работа твоего приложения будет заключаться в бессмысленном мапинге одних сущностей на другие?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Tom, Вы писали:
Tom>Зачем нужно хранить TSQL отдельно от кода — в первую очередь что бы иметь нормальную возможность провалидировать этот TSQL и рефакторить его отдельно от кода.
Кстати, забыл про SQL отдельно от кода. Иногда приложение можно существенно оптимизировать, генерируя и оптимизируя код SQL на клиенте. За примером далеко ходить не надо — это наш сайт и конкретно MainList.aspx. Переписывание кода со статического SQL на Linq2SQL решило проблему, над которой мы бились несколько лет, пытаясь тщетно подкрутить монстрообразный запрос индексами и хинтами.
Так же напрочь убивается повторное использование кода. Десять запросов, отличающихся одной колонкой — это будет десять SQL-ей, вместо одного с параметром.
Если нам не помогут, то мы тоже никого не пощадим.
IT>Начнём с того, что всё это элементарно не имеет никакого смысла. Самое сложное в DAL — это рутина ручной набивки аксессоров, которая хоть так хоть эдак уходит. После этого при разработке, например, какой-нибудь формы или отчёта, на разработку SQL запроса уходит два часа, на DAL и BL пять минут, а на UI неделя. Ну давай добавим ещё две минуты на твой ad hoc класс. На неделю UI это всё равно никак не повлияет. Не там ты оптимизируешь.
Да, но ты забываешь про поддержку. Дело в том, что генерацию хочется использовать не по моей прихоти. А по нужде так сказать.
Сейчас я думаю у нас около тысячи OLEDB акцэсоров, и поверь мне это один из самых геморойных мест проекта.
Так же ты забываешь про рефакторинг и compile time проверку соответствия кода и базы.
Когда мы пишем руками — мы не имеем ни первого ни второго.
Так же про проверку TSQL. Если он у тебя в коде — то ты вообще в полной засаде.
IT>Но допустим вы нагенерировали кучу ad hoc классов. Сразу возникает несколько вопросов.
IT>1. Для запросов SELECT * FROM Person и SELECT * FROM Person WHERE ID = 1 у тебя будет генерироваться один класс или два?
Два по умолчанию. Но будет возможность явно указать Entity класс. Нужно это по нескольким причинам:
1. К сожалению у нас есть CLR based stored procedures. Для них невозможно получить метаданные на основе FMTONLY
2. Что бы в некоторых случаях не мапить одно на другое, хотя реально таких мест будет очень мало.
IT>2. Как ты собираешься задавать имена своим классам?
По ими файла ad hoc запроса. Кстате я забыл упомянуть что в ad hoc запросы как и в хранимки можно будет передавать параметры.
Таким образом мы получим что то среднее между хранимыми процедурами и обычными запросами.
Среднее в том плане, что сами запросы будут отделены от кода, но всё же будут жить на клиенте.
Сторы сейчас одна из основных болей для нас, так как обновление базы в случае их применения — это гарантированный down time для On-Demand систем.
IT>3. Все свои классы ты будешь хранить в одном namespace или в разных? Как это задавать?
Вариантов миллион. Самый простой при помощи каталогов. Если надо группировать запросы в namespace — создавай каталог.
IT>4. Готов ли ты к тому, что основная работа твоего приложения будет заключаться в бессмысленном мапинге одних сущностей на другие?
Не готов и очень хочется этого избежать.
IT>Так же напрочь убивается повторное использование кода. Десять запросов, отличающихся одной колонкой — это будет десять SQL-ей, вместо одного с параметром.
Так параметры можно будет использовать, ессно они нужны.
А по поводу генерации прямо в коде, тут есть свои за и против.
Скажем так, я против того что бы такой подход использовать повсеместно, но как исключение из правила — почему нет
Здравствуйте, Tom, Вы писали:
Tom>Зачем нужно хранить TSQL отдельно от кода — в первую очередь что бы иметь нормальную возможность провалидировать этот TSQL и рефакторить его отдельно от кода. Tom>Например при помощи той же VSTS Database Edition GDR.
Tom>Можешь на примерах как то описать принципиальные ошибки в таком подходе?
То что ты описал, только без приседаний с выносом SQL-я в одтдельные фалы сделали в виде макры несколько лет назад: http://nemerle.org/SQL_macros
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Tom, Вы писали:
IT>>Так же напрочь убивается повторное использование кода. Десять запросов, отличающихся одной колонкой — это будет десять SQL-ей, вместо одного с параметром. Tom>Так параметры можно будет использовать, ессно они нужны.
SELECT * Table WHERE Field1 = 1
SELECT * Table WHERE Field2 = 1
Как ты тут будешь использовать параметры?
Tom>А по поводу генерации прямо в коде, тут есть свои за и против. Tom>Скажем так, я против того что бы такой подход использовать повсеместно, но как исключение из правила — почему нет
Почему против, какие аргументы?
Если нам не помогут, то мы тоже никого не пощадим.
SELECT * Table WHERE Field2 = @local_Field2
Проблем не вижу. Генератор по формату имени поймёт что это параметр передаваемый из вне а не локальная переменная использующаяся в скрипте.
Tom>>А по поводу генерации прямо в коде, тут есть свои за и против. Tom>>Скажем так, я против того что бы такой подход использовать повсеместно, но как исключение из правила — почему нет IT>Почему против, какие аргументы?
Да я вроде уже не раз писал аргументы, тут например Re[11]: Nemerle & Real Life
основная причина разделения C# и TSQL кода — это вопросы поддержки.
Когда TSQL живёт внутри C# эта поддержка на порядок усложняется.
А так же исчезает compile time проверка этого TSQL.
Здравствуйте, Tom, Вы писали:
Tom>Да, но ты забываешь про поддержку.
Я как раз о ней и говорю.
Tom>Дело в том, что генерацию хочется использовать не по моей прихоти. А по нужде так сказать. Tom>Сейчас я думаю у нас около тысячи OLEDB акцэсоров, и поверь мне это один из самых геморойных мест проекта.
От тысячи аксессоров мне не страшно. Во-первых, много в программировании это не всегда хорошо, а чаще совсем наоборот. Во-вторых, как я уже говорил, главное устранить набивку кода внутри аксессоров. А это можно сделать разными способами.
Tom>Так же ты забываешь про рефакторинг и compile time проверку соответствия кода и базы. Tom>Когда мы пишем руками — мы не имеем ни первого ни второго.
Как это не имеем? А как же Linq2Sql?
Tom>Так же про проверку TSQL. Если он у тебя в коде — то ты вообще в полной засаде.
В полной заднице ты только, если размазываешь SQL по всему коду в виде конкатенации строк. DAL как раз и был придуман, чтобы эту задницу существенно уменьшить. А если использовать linq, то задницы вообще никакой нет.
IT>>Но допустим вы нагенерировали кучу ad hoc классов. Сразу возникает несколько вопросов.
IT>>1. Для запросов SELECT * FROM Person и SELECT * FROM Person WHERE ID = 1 у тебя будет генерироваться один класс или два? Tom>Два по умолчанию. Но будет возможность явно указать Entity класс.
Каким образом?
IT>>2. Как ты собираешься задавать имена своим классам? Tom>По ими файла ad hoc запроса.
Я думал, что по имени файла лучше именовать метод аксессора. Но допустим это будет имя возращаемого типа. Тогда такой вопрос. Как будет именоваться имя метода аксессора. Как вы будете решать такую проблему. Ваш метод возвращает информацию для одного типа, но в одном случае это Person, во втором List<Person>, в третьем Dictionary<int,Person>? Нужно ещё как-то уметь задавать возвращаемые значения как скалярные типы.
IT>>3. Все свои классы ты будешь хранить в одном namespace или в разных? Как это задавать? Tom>Вариантов миллион. Самый простой при помощи каталогов. Если надо группировать запросы в namespace — создавай каталог.
Понятно. В наличии у нас имя файла и имя каталога. А нужно имён в количестве: namespace, class name, method name, entity name. Плюс нужно выбрать метод Execute (ExecuteScalar, ExecuteList, ExecuteDictionary).
IT>>4. Готов ли ты к тому, что основная работа твоего приложения будет заключаться в бессмысленном мапинге одних сущностей на другие? Tom>Не готов и очень хочется этого избежать.
Готовься.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Tom, Вы писали:
Tom>SELECT * Table WHERE Field2 = @local_Field2 Tom>Проблем не вижу. Генератор по формату имени поймёт что это параметр передаваемый из вне а не локальная переменная использующаяся в скрипте.
Ты не понял. Ещё раз.
SELECT * Table WHERE Field1 = 1
SELECT * Table WHERE Field2 = 1
Разные поля, используемые в запросе, а не значение параметра. Редко, но бывает нужно.
Tom>>>А по поводу генерации прямо в коде, тут есть свои за и против. Tom>>>Скажем так, я против того что бы такой подход использовать повсеместно, но как исключение из правила — почему нет IT>>Почему против, какие аргументы? Tom>Да я вроде уже не раз писал аргументы, тут например Re[11]: Nemerle & Real Life
Это ссылка на моё сообщение.
Tom>основная причина разделения C# и TSQL кода — это вопросы поддержки. Tom>Когда TSQL живёт внутри C# эта поддержка на порядок усложняется. Tom>А так же исчезает compile time проверка этого TSQL.
Это ты про то как у вас было раньше или у тебя есть реальный опыт использования этого в других условиях, особенно с linq?
Если нам не помогут, то мы тоже никого не пощадим.
Tom>>Так же ты забываешь про рефакторинг и compile time проверку соответствия кода и базы. Tom>>Когда мы пишем руками — мы не имеем ни первого ни второго. IT>Как это не имеем? А как же Linq2Sql?
Он идёт в лес по целому ряду причин. Тут я с Владом согласен что идея недодуманная совсем. И проект скорее мёртв чем жив, MS в него ресурсы вкладывать не будет.
Ну и опять это перенос в код запростов TSQL, хоть и не в явном виде, что опять же усложняет рефакторинг базы.
Который кстате намечается серьёзный.
И мы обсуждали проблемы моей кодогенерации а не линк. У линка заметь опять же своя кодогенерация. И для стор между прочим он генерирует resultset файл. Ну или акцэсор. Незнаю как лучше назвать.
Я проблем пока реальных на примерах так и не увидел. Есть некоторые нюансы конечно но шоу стоперов реальных я пока не вижу.
Tom>>Так же про проверку TSQL. Если он у тебя в коде — то ты вообще в полной засаде. IT>В полной заднице ты только, если размазываешь SQL по всему коду в виде конкатенации строк. DAL как раз и был придуман, чтобы эту задницу существенно уменьшить. А если использовать linq, то задницы вообще никакой нет.
Размазывания в виде конткатенаций скорее всего ожидать не стоит, а вот размазывания по разным C# файлам и возможно сборкам вполне (это если писать TSQL в коде)
А насчёт линка мне кажется ты немного наивен. Если взять подмножество linq2sql и TSQL 2008 то первый наверное и 20% не реализует.
Какой смысл себя ограничивать так? Тем более что у нас запросы обычно сложные. Нам тут всю мощ TSQL хочется иметь.
IT>>>Но допустим вы нагенерировали кучу ad hoc классов. Сразу возникает несколько вопросов.
IT>>>1. Для запросов SELECT * FROM Person и SELECT * FROM Person WHERE ID = 1 у тебя будет генерироваться один класс или два? Tom>>Два по умолчанию. Но будет возможность явно указать Entity класс. IT>Каким образом?
Явным, в конфиге. Кодогенерация не означает того что она не будет конфигурируемая. Но надобности в таких вещах не будет практически (в теории). Можно задавать опять же неявно, вариантов много на самом деле. Например группировать TSQL который работает с некоторой одной entity в одном каталоге/namespace-е. Чем не вариант. naming использовать. Разные можно придумать варианты.
IT>>>2. Как ты собираешься задавать имена своим классам? Tom>>По ими файла ad hoc запроса.
IT>Я думал, что по имени файла лучше именовать метод аксессора. Но допустим это будет имя возращаемого типа. Тогда такой вопрос. Как будет именоваться имя метода аксессора.
Я тут думаю тебе лечше посмотреть как это делает например тот еж линк для стор. В нашем случае имя файла ad hoc запроса будет играть роль имени базового на основе которого будут строится другие имена.
IT>Ваш метод возвращает информацию для одного типа, но в одном случае это Person, во втором List<Person>, в третьем Dictionary<int,Person>? Нужно ещё как-то уметь задавать возвращаемые значения как скалярные типы.
С скалярными значениями, их просто лучше избегать. Тем более что мы движемся в сторону ad hoc запростов вместо хранимок. А вот с тем возвращать ли коллекцию или один обьект — это хороший вопрос. На вскидку. Для таблицы будут генерироваться не только C# но и CRUD TSQL. Таким образом нам надо только таблица и мы по ней сможем сгенерировать SelectAll/SelectById/Insert/Delete/Update C# с TSQL-ем в нём. В этом случае мы чётко знаем что возвращается.
Задача сводится к тому как понять, что возвращает некоторый ad hoc/sp. Одну сущность или коллекцию.
Буду думать, возможно забиться на имя файла. Или опять же как то каталоги использовать.
Если тут подумать то имя файла/каталог/конфиг — всё это мета информация заданная просто разными способами.
Надо просто подобрать более удобный.
Хороший нюанс кстате. буду думать.
IT>>>3. Все свои классы ты будешь хранить в одном namespace или в разных? Как это задавать? Tom>>Вариантов миллион. Самый простой при помощи каталогов. Если надо группировать запросы в namespace — создавай каталог.
IT>Понятно. В наличии у нас имя файла и имя каталога. А нужно имён в количестве: namespace, class name, method name, entity name. Плюс нужно выбрать метод Execute (ExecuteScalar, ExecuteList, ExecuteDictionary).
Игрь вопросы именования уже решаются в существующих framework-ах. И принципиальных проблем я не вижу тут. Ну будет базовое имя и на его основе будут строится другие имена. В чём сложность то?
IT>Готовься.
А я геморой и сзади не боюсь У меня на него стойкая имунная реакция выработалась за годы профессиональной деятельности
IT>Разные поля, используемые в запросе, а не значение параметра. Редко, но бывает нужно.
А, понятно, дело в том что от обезьяны с гранатой спасения нет.
Особенно если туда ещё и условие присобачить.
Но и задачи спастить от идиота не ставится.
Ну и у нас код ревью есть абсолютно всех changeset-ов.
Такое можно вылавливать.
Tom>>>>А по поводу генерации прямо в коде, тут есть свои за и против. Tom>>>>Скажем так, я против того что бы такой подход использовать повсеместно, но как исключение из правила — почему нет IT>>>Почему против, какие аргументы? Tom>>Да я вроде уже не раз писал аргументы, тут например Re[11]: Nemerle & Real Life
IT>Это ссылка на моё сообщение.
Акела промахнулся. Моё рядышком.
Tom>>основная причина разделения C# и TSQL кода — это вопросы поддержки. Tom>>Когда TSQL живёт внутри C# эта поддержка на порядок усложняется. Tom>>А так же исчезает compile time проверка этого TSQL.
IT>Это ты про то как у вас было раньше или у тебя есть реальный опыт использования этого в других условиях, особенно с linq?
Конечно из жизни. Тяжёлой и горькой Если хочешь можно с примерами. С линком есть опыт но небольшой и не менее горький.
В наших проектах он не применим из за убогости. да и смысла применять мёртвый проект я не вижу.
Ну и опять же это перенос TSQL в не явном виде в код. Что полюбому усложняет поддержку рефакторинг.
Здравствуйте, Tom, Вы писали:
IT>>Как это не имеем? А как же Linq2Sql? Tom>Он идёт в лес по целому ряду причин. Тут я с Владом согласен что идея недодуманная совсем.
Влад говорит не о ряде причин, а том, что в linq2sql неверно сделаны insert/update/delete. Зато select, который нужен в 90% случаев, сделан вполне добротно. А что ещё есть в твоём ряде причин?
Tom>И проект скорее мёртв чем жив, MS в него ресурсы вкладывать не будет.
Ну так MS и в твой генератор ресурсы вкладывать не будет.
Tom>Ну и опять это перенос в код запростов TSQL, хоть и не в явном виде, что опять же усложняет рефакторинг базы. Tom>Который кстате намечается серьёзный.
Как раз linq2sql позволяет проводит рефакторинг базы с применением компилятора C# и студии. А что даст твой валидатор SQL? Список ошибок на экране? И что ты с ним будешь делать?
Tom>И мы обсуждали проблемы моей кодогенерации а не линк. У линка заметь опять же своя кодогенерация. И для стор между прочим он генерирует resultset файл. Ну или акцэсор. Незнаю как лучше назвать.
Что касается спроков, то здесь у BLToolkit конкурентов нет. Вообще.
Tom>Я проблем пока реальных на примерах так и не увидел. Есть некоторые нюансы конечно но шоу стоперов реальных я пока не вижу.
Дело не в стоперах, дело в замедлителях и заколебателях. Для конкретных примеров, как я уже говорил, заведи себе тетрадочку.
Tom>Размазывания в виде конткатенаций скорее всего ожидать не стоит, а вот размазывания по разным C# файлам и возможно сборкам вполне (это если писать TSQL в коде)
А ты всё в одном файле и в одном классе собираешься держать?
Tom>А насчёт линка мне кажется ты немного наивен. Если взять подмножество linq2sql и TSQL 2008 то первый наверное и 20% не реализует. Tom>Какой смысл себя ограничивать так? Тем более что у нас запросы обычно сложные. Нам тут всю мощ TSQL хочется иметь.
Остальные 80% элементарно достигаются применением таблиц-функций и получающимся смешанным стилем клиентский код/SQL.
Tom>>>Два по умолчанию. Но будет возможность явно указать Entity класс. IT>>Каким образом? Tom>Явным, в конфиге.
Т.е. на каждый запрос ещё и строчка в конфиге. Круто! Лучше ещё немного подумай, может быть окажется, что проще использовать специализированные комментарии в самом SQL.
Tom>Кодогенерация не означает того что она не будет конфигурируемая. Но надобности в таких вещах не будет практически (в теории). Можно задавать опять же неявно, вариантов много на самом деле. Например группировать TSQL который работает с некоторой одной entity в одном каталоге/namespace-е. Чем не вариант. naming использовать. Разные можно придумать варианты.
Это, конечно, очень удобно, иметь 1000 файлов в 500 каталогах в каждом по 2 файла, а то и по одному.
IT>>Я думал, что по имени файла лучше именовать метод аксессора. Но допустим это будет имя возращаемого типа. Тогда такой вопрос. Как будет именоваться имя метода аксессора. Tom>Я тут думаю тебе лечше посмотреть как это делает например тот еж линк для стор. В нашем случае имя файла ad hoc запроса будет играть роль имени базового на основе которого будут строится другие имена.
PersonNamespace_Person_List_GetPersonByCriteria15?
IT>>Ваш метод возвращает информацию для одного типа, но в одном случае это Person, во втором List<Person>, в третьем Dictionary<int,Person>? Нужно ещё как-то уметь задавать возвращаемые значения как скалярные типы. Tom>С скалярными значениями, их просто лучше избегать.
Лучше избегать ограничений, под которые подгоняется дизайн приложения только потому, что он не вписываются в какой-то там генератор. Ты ещё не начал ничего делать, а искусственных ограничений уже насочинял. Осталось только подогнать под них какую-нибудь заумную теорию или паттерн, тем самым окончательно убедив себя в необходимости жить в строго ограниченных рамках.
Впрочем, я такое наблюдаю всегда, когда архитектура строится на прекомпалтайм генерации кода. Видимо, это происходит потому что не ты контролируешь код, а код контролирует тебя. Ты уверенно движешься в том же направлении.
Tom>Тем более что мы движемся в сторону ad hoc запростов вместо хранимок. А вот с тем возвращать ли коллекцию или один обьект — это хороший вопрос. На вскидку. Для таблицы будут генерироваться не только C# но и CRUD TSQL. Таким образом нам надо только таблица и мы по ней сможем сгенерировать SelectAll/SelectById/Insert/Delete/Update C# с TSQL-ем в нём. В этом случае мы чётко знаем что возвращается.
Это CRUDL. Как я уже говорил, эта задача решается вообще без всяких генераторов одним библиотечным кодом. Более того генерировать CRUDL — это генерировать кучу невостребованного мусора. Дай бог, чтобы ты использовал хотя бы 20% от сгенерированного.
Tom>Задача сводится к тому как понять, что возвращает некоторый ad hoc/sp. Одну сущность или коллекцию. Tom>Буду думать, возможно забиться на имя файла. Или опять же как то каталоги использовать.
Специализированные комментарии в SQL помогут отцу генерации.
Tom>Если тут подумать то имя файла/каталог/конфиг — всё это мета информация заданная просто разными способами. Tom>Надо просто подобрать более удобный.
Вот именно. И лучшая метаинформация — это декларация непосредственно в коде.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Tom, Вы писали:
IT>>Разные поля, используемые в запросе, а не значение параметра. Редко, но бывает нужно. Tom>А, понятно, дело в том что от обезьяны с гранатой спасения нет.
Обезъяна с гранатой не знает что с ней делать. А если гранатой умело воспользоваться, то можно легко изничтожить тонны тупого копипейстного кода. И поддержка такого кода только выигрывает.
Tom>Особенно если туда ещё и условие присобачить. Tom>Но и задачи спастить от идиота не ставится. Tom>Ну и у нас код ревью есть абсолютно всех changeset-ов. Tom>Такое можно вылавливать.
Что вылавливать, копипейст? Выловил и что дальше?
IT>>Это ты про то как у вас было раньше или у тебя есть реальный опыт использования этого в других условиях, особенно с linq? Tom>Конечно из жизни. Тяжёлой и горькой
Из той прошлой жизни на C++? Или ты уже и в новой успел поприменять старые методы?
Tom>Если хочешь можно с примерами. С линком есть опыт но небольшой и не менее горький. Tom>В наших проектах он не применим из за убогости. да и смысла применять мёртвый проект я не вижу. Tom>Ну и опять же это перенос TSQL в не явном виде в код. Что полюбому усложняет поддержку рефакторинг.
Я не знаю кто тебе такое напел, но видимо ты либо неправильно понял, либо плохо разобрался. За технологиями вроде Linq будущее. Не за прекомпайл-тайм генераторами кода, которые всё никак вот уже лет 20 не завоюют мир, а именно за генерацией кода в run-time, а ещё лучше в compile-time.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Tom, Вы писали:
Tom>>>Так же ты забываешь про рефакторинг и compile time проверку соответствия кода и базы. Tom>>>Когда мы пишем руками — мы не имеем ни первого ни второго. IT>>Как это не имеем? А как же Linq2Sql? Tom>Он идёт в лес по целому ряду причин. Тут я с Владом согласен что идея недодуманная совсем. И проект скорее мёртв чем жив, MS в него ресурсы вкладывать не будет.
Linq2SQL уже развиваться не будет, смотрите в сторону EF.
Tom>Ну и опять это перенос в код запростов TSQL, хоть и не в явном виде, что опять же усложняет рефакторинг базы. Tom>Который кстате намечается серьёзный.
У вас рефакторинг БД случается чаще\имеет больший объем, чем рефакторинг кода?
Tom>А насчёт линка мне кажется ты немного наивен. Если взять подмножество linq2sql и TSQL 2008 то первый наверное и 20% не реализует. Tom>Какой смысл себя ограничивать так? Тем более что у нас запросы обычно сложные. Нам тут всю мощ TSQL хочется иметь.
Инкапсулируйте сложность на уровне БД, создавайте вьюхи для развесистых выборок, используйте хранимки, не возвращающие результат, для операций изменения данных.
Кроме того Linq2SQL позволяет скалярные функции использовать в теле запросов. EF покачто такого не умеет.
Tom>Явным, в конфиге. Кодогенерация не означает того что она не будет конфигурируемая. Но надобности в таких вещах не будет практически (в теории). Можно задавать опять же неявно, вариантов много на самом деле. Например группировать TSQL который работает с некоторой одной entity в одном каталоге/namespace-е. Чем не вариант. naming использовать. Разные можно придумать варианты.
Со временем ручной кодинг таких вариантов будет отнимать все больше времени.
IT>Обезъяна с гранатой не знает что с ней делать. А если гранатой умело воспользоваться, то можно легко изничтожить тонны тупого копипейстного кода. И поддержка такого кода только выигрывает.
Игорь, но ведь ьты предлагаешь писать больше кода. Как минимум классы resultset-ов.
IT>Что вылавливать, копипейст? Выловил и что дальше?
Мне кажется это уже не конструктивно.
IT>Из той прошлой жизни на C++? Или ты уже и в новой успел поприменять старые методы?
Опять же это не тот стиль в котором можно прийти к чему то конструктивному
IT>Я не знаю кто тебе такое напел, но видимо ты либо неправильно понял, либо плохо разобрался. За технологиями вроде Linq будущее. Не за прекомпайл-тайм генераторами кода, которые всё никак вот уже лет 20 не завоюют мир, а именно за генерацией кода в run-time, а ещё лучше в compile-time.
Напела мне жизнь. Допустим в линке есть некоторая поддержва в явном виде выборки данных. и нету поддержки UPDADE/DELETE/INSERT. В выборке данных есть поддержка всего процентов наверное 10-20 от всей мощи TSQL. Вопрос, нахрена козе баян? И что делать с действительно сложными запросами, которых у нас в огромном количестве. Да и смысла подменять один язык TSQL другим linq я не вижу. Тем более, что ты упорно игнорируешь тот факт что он мёртв.
Если нам не помогут, то мы тоже никого не пощадим.
У меня на него стойкая имунная реакция выработалась за годы профессиональной деятельности 
