Tom>>Можешь пояснить как может выглядеть собственный DSL для работы с данными? Что принципиально будет в нём отличного от того же TSQL? VD>Принципиально ничего. Но он будет встроен в полноценный язык (и удобный) программирования. Ты получаешь возможность писать весь код приложения на одном языке.
Получается что, вместо использование/написания провайдера linq нормальный подход — свой DSL для работы с данными. Так?
Есть ли уже готовые примеры?
VD>Кто мы такие чтобы мешать тебе? Пробуй... VD>Но это же ты пришел к нам и задаешь вопросы, правда? Вот мы тебе и отвечаем, что нам компромиссы подобные описанным тобой не нравятся.
да, да да и большое спасибо за ответы!
Здравствуйте, Tom, Вы писали:
Tom>И всё же, какой провайдер ты предлагаешь использовать СЕЙЧАС. Не завтра и не после завтра, а сейчас?
Я же тебе ответил. Зависит от задач. Лично тебе подошел бы linq2sql, так как ты работаешь с одной СУБД.
IT обещал закончить провайдер в течении 1-2 месяцев. Если это произойдет, то его провайдер будет предпочтительнее.
VD>>Одни говорят (давно), а другие делают. Улавливаешь разницу? Tom>А я по твоему ничего не делаю? Просто ты волен заниматсья тем что тебе интересно, а мне приходится работать в реальных проектах с большой и многолетней историей (более 15 лет) и огромный количеством кода. Если формально посчитать — то более 100 мегабайт.
Я как бы и не скрывал, что в этом отношении у меня есть некоторое приемущество. Но тот же IT в том же положении, что и ты. Но он выбирает другой путь.
Tom>Он уже огромный, и я его уменьшаю в разы. По моим оченкам обьём кода я смогу уменьшить на порядок
Рад за твои оценки. Расскажи потом, чем дело кончилось. Кстати, процедуры аналогичные приведенной тобой я бы подверг рефакторингу. Это монстр, а не код. Его точно поддерживать будет сложно.
Tom>Какие примочки и причём тут гнилапя база? Для MS SQL Server — а единственный язык общения — это TSQL.
Я уже говорил об этом. TSQL — это кривой и очень примитивный скрипт в который встроена поддержка SQL. Равития у него нет. Его латают по скорому, чтобы хоть как-то использовать можно было.
Я на этом говне писал еще в 1995 году и могу сравнивать с тем, что есть сейчас. Отличия можно пересчитать по пальцам одной руки.
И вообще, если TSQL так крут, то зачем тебе вообще C# сдался? Пиши все на TSQL.
VD>>При этом тот же "поставщик" предлагает конкретное решение — linq + современные дотнет-языки. И это решение действительно развивается. Tom>От MS реального решения для работы с данными пока нет. И тем более нет решения позволяющего правно смигрировать с существующего кода.
Это ты себя убеждаешь в этом. А реально оно есть. Не совершенное пока, но есть.
Tom>Влад, ты какой нибудь другой язык который понимает SQL сервер?
Этот язык называется SQL. Его возможностей достаточно для работы с данными из БД. А разные TSQL-и и PL-SQL — это попытка прикрутить скрипты в СУБД. Причем TSQL просто провальная попытка, а PL-SQL кривенькая, но рабочая.
Linq же решает очень похожую задачу, только вместо того чтобы выдумывать кривой скрипт, Linq предоставляет средства для встраивания запросов в любой язык. Ну, с DML пока недоработка. Но сам подход намньго более верный.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Tom, Вы писали:
Tom>Получается что, вместо использование/написания провайдера linq нормальный подход — свой DSL для работы с данными. Так?
Свое расширение для DML. Linq отлично справляется с запросной частью. Ну, может быть какое-то решение для тех же оптимизаций придумать.
Tom>Есть ли уже готовые примеры?
Я не занимался этим вопросом. Знаю только, что IT близок к созданию своего провайдера который точно будет поддерживать DML.
VD>>Кто мы такие чтобы мешать тебе? Пробуй... VD>>Но это же ты пришел к нам и задаешь вопросы, правда? Вот мы тебе и отвечаем, что нам компромиссы подобные описанным тобой не нравятся. Tom>да, да да и большое спасибо за ответы!
На здоровье. Я это к тому сказал, чтобы ты не воспринимал наши слова как навязывание тебе нашего мнения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Tom, Вы писали:
VD>>Какой вам больше по душе. Если вы ориентируетесь исключительно на MS SQL Server, то наверно linq2sql — лучший выбор. Tom>Опять двадцать пять. Этот проект мёртв. Ещё предложения?
Что за чушь? Его не сделают кроссерверным и не будут развивать такими же темпами как EF. Но поддерживать будут, так как он уже часть фрэймворка.
Tom> И что всё таки делать с linq & DML?
Реализовать самому или дождаться пока появится провайдер со встроенным DML.
Вариант 3 — использовать обновление объектов и датаконтекст (он мне самому не нравится).
Tom>Понятно, спасибо. Это на мой взгляд невозможно, и глупо. невозможно потому что linq как ты сам писал не поддерживает DML а глупо потому что от того что масло станет маслянным качество проекта не улучшится.
Сколько у вас там сложных запросов использующих DML (за исключением манипуляции с временными таблицами)?
Ну, и оставьте их в виде хранимок. Это один черт лучше чем все держать в вдие TSQL-я.
VD>>Ты просто плохо в нем разобрался. Там есть лишнее, но его можно не использовать. Проблемы EF в другом. Он плохо поддерживает функционал конкретной СУБД. Работа с датами, например, там не к черту не годится. Отсюда многие агрегатные запросы могут просто не получиться реализовать. Tom>Кы читал куда они двигаются/развиваются?
Да. Но схему linq2sql они накрывают полностью, так что можешь просто не использовать то что тебе не нужно.
Tom>Вот что исходники откроют я верю. Как раз из за проблем поддержки. Что бы спихнуть её на комьюнити. Но без открытия исходников компилятора нормально линк развивать не получится. Тот же DML полностью не реализовать, да и я не представляю сколько для этого понадобится ресурсов.
DML реализовать можно, хотя и сложно. А что там еще развивать то?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Рад за твои оценки. Расскажи потом, чем дело кончилось. Кстати, процедуры аналогичные приведенной тобой я бы подверг рефакторингу. Это монстр, а не код. Его точно поддерживать будет сложно.
Да я бы тоже их подверг, что и придётся делать скоро. Но рефакторинг будет связан с новой большой ыичей из за которого пол базы придётся перелопатить.
заметки на полях я колнечно буду делать и потом расскажу что вышло. Вполне возможно что подход пойдёт в мусорку и надо будет думать что то другое.
Tom>>Какие примочки и причём тут гнилапя база? Для MS SQL Server — а единственный язык общения — это TSQL.
VD>Я уже говорил об этом. TSQL — это кривой и очень примитивный скрипт в который встроена поддержка SQL. Равития у него нет. Его латают по скорому, чтобы хоть как-то использовать можно было. VD>Я на этом говне писал еще в 1995 году и могу сравнивать с тем, что есть сейчас. Отличия можно пересчитать по пальцам одной руки.
VD>И вообще, если TSQL так крут, то зачем тебе вообще C# сдался? Пиши все на TSQL.
Ну логику обоработки данных иы и пишем на TSQL.
VD>>>При этом тот же "поставщик" предлагает конкретное решение — linq + современные дотнет-языки. И это решение действительно развивается. Tom>>От MS реального решения для работы с данными пока нет. И тем более нет решения позволяющего правно смигрировать с существующего кода.
VD>Это ты себя убеждаешь в этом. А реально оно есть. Не совершенное пока, но есть.
Tom>>Влад, ты какой нибудь другой язык который понимает SQL сервер?
VD>Этот язык называется SQL. Его возможностей достаточно для работы с данными из БД. А разные TSQL-и и PL-SQL — это попытка прикрутить скрипты в СУБД. Причем TSQL просто провальная попытка, а PL-SQL кривенькая, но рабочая.
Интерено про PL-SQL и TSQL детали. Я с PL-SQL сталкивался так давно что не помню практически ничего.
VD>Linq же решает очень похожую задачу, только вместо того чтобы выдумывать кривой скрипт, Linq предоставляет средства для встраивания запросов в любой язык. Ну, с DML пока недоработка. Но сам подход намньго более верный.
Так я и не смпорбю что ВЕКТОР правильный, а реализация пока кривенькая. Вот будет DML тогда и будем переписывать.
Хотя для некоторых сложных запросов мы попытаемся сделать декомпозицию с помощью линка. Посмотрим насколько это реально.
Здравствуйте, Tom, Вы писали:
Tom>Нет. Сам подход, как ВЕКТОР мне нравится. Не нравится что это очередное недоделанное решение. Опять же возвращаясь к DML.
Ну, и нам нравится сам подход, но не его сегодняшная реализация. EF и правда идет не туда. DML и правда необходим.
И мы хотим просто плюнуть на МС который шатает то туда, то сюда и сделать все сами так как считаем нужным.
Tom>Я не против использовать линк если будет чётко ясно что; Tom>1. Решение обеспечивает эволюционную модель развития приложения. Переписать всё с нуля — такой подход не работает
Ну, уж тут придется что-то делать. Понятно, что по мановению волшебной палочки TSQL не превратится в linq.
Можно переписывать проект по мере необходимости. Скажем встала задача изменить то-то и то-то, меняем связанную с этим реализацию на linq...
Tom>2. Я смогу перенести все текущие запросы и linq будет полностью хватать для обработки данных в нашей системе
Это само собой разумеется. Кроме CTE (т.е. рекурсивных запросов) все остальное на linq переносится.
Tom>Но если посмотреть реально на ситуацию то такого не произойдёт в ближайшем будущем. Tom>Ибо, сама идея EF+linq 2 entity не правильная. А linq2sql мёртвая.
Опять возвращаемся к исходным посылкам. Ты исходишь из посылок, что за тебя все должны сделать и предложить тебе законченное (и идеально сделанное) решение. Мы исходим из того, что решения удовлетворяющего нас на 100% нет. Но есть подход который можно развить до необходимого решения.
Мы предлагаем создасть свое решение и насрать на Майкрософт, таз уж их там колбасит по черному.
Ты же предлагаешь реализовть какой-то некрасивый компромис и пользоваться убогим транзактом.
Подходы в общем-то чем-то похожи. Оба имеют цель сделать собственное решение. Но твой подход — это половичатое решение которое по любому создаст кучу проблем.
Реален ли твой подход? Наверно — да! Но лично мне он не нравится.
Tom>Вместо неё M$ надо было заняться обьектной базой и запросами к ней.
Ну, чем им там надо было бы заняться не нам с тобой решать. А то в этом форуме было бы более уместно обсудить вопрос почему МС развивает C# и F#, а не Nemerle. Казалось бы многие задаются этим вопросом, а в МС даже ответить на него не хотят.
Тем более, что вопрос ООБД крайне спорный. Я не считаю ООБД перспективной идеей. ООП банально более примитивная технология нежели ФП. Современные СУБД гораздо ближе к ФП и потому их средства обработки данных (запросы) намного мощнее.
Tom>Вот тогда всё бы стало на свои места. Пишем себе на managed языке обьекты, сохраняим их в обьектнуцю БД и выбираем данные на том же языке на котором описаны сами данные.
Ты меня извини, но я тебе скажу правду от которой ты можешь обидится, но эта действительно правда. Ты смотришь на мир глазами незнайки. ООП далеко не лучшее решение во всех случаях. Обработка данных — это как раз тот случай где ООП практически ничего путного предложить не может.
Задумайся над тем почему ты исползуешь транзакт, а не пишешь все на С#? Или даже поставим вопрос так. Почему ты в транзакте используешь SQL?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Опять возвращаемся к исходным посылкам. Ты исходишь из посылок, что за тебя все должны сделать и предложить тебе законченное (и идеально сделанное) решение. Мы исходим из того, что решения удовлетворяющего нас на 100% нет. Но есть подход который можно развить до необходимого решения. VD>Мы предлагаем создасть свое решение и насрать на Майкрософт, таз уж их там колбасит по черному. VD>Ты же предлагаешь реализовть какой-то некрасивый компромис и пользоваться убогим транзактом.
VD>Подходы в общем-то чем-то похожи. Оба имеют цель сделать собственное решение. Но твой подход — это половичатое решение которое по любому создаст кучу проблем. VD>Реален ли твой подход? Наверно — да! Но лично мне он не нравится.
Ну сказать что бы он мне сильно нравился я такого не скажу. Я просто попытался придумать меньшую из зол.
А написать своё провайдер или DSL дял работы с данными так меня просто не поймут.
Представь сколько усилий понадобится на поддержку и развитие этого решения.
Да и работа с данными станет проще конечно но не на порядок.
Tom>>Вместо неё M$ надо было заняться обьектной базой и запросами к ней.
VD>Ну, чем им там надо было бы заняться не нам с тобой решать. А то в этом форуме было бы более уместно обсудить вопрос почему МС развивает C# и F#, а не Nemerle. Казалось бы многие задаются этим вопросом, а в МС даже ответить на него не хотят.
Я думаю эту ветку просто перенести можно, немерл тут офтопик пока.
VD>Тем более, что вопрос ООБД крайне спорный. Я не считаю ООБД перспективной идеей. ООП банально более примитивная технология нежели ФП. Современные СУБД гораздо ближе к ФП и потому их средства обработки данных (запросы) намного мощнее.
О, тогад вопрос, есть ли смысл в linq 2 entity? Ведь это попытка как я понимаю как раз делать запросы над некой обьектной структурой.
Tom>>Вот тогда всё бы стало на свои места. Пишем себе на managed языке обьекты, сохраняим их в обьектнуцю БД и выбираем данные на том же языке на котором описаны сами данные.
VD>Ты меня извини, но я тебе скажу правду от которой ты можешь обидится, но эта действительно правда. Ты смотришь на мир глазами незнайки. ООП далеко не лучшее решение во всех случаях. Обработка данных — это как раз тот случай где ООП практически ничего путного предложить не может.
А гед я спорю с этим? Именно по этому я не предлагаю например всякую чёрную магию в виде ORM итп... А обрабатываю данные при помощи запросов
VD>Задумайся над тем почему ты исползуешь транзакт, а не пишешь все на С#? Или даже поставим вопрос так. Почему ты в транзакте используешь SQL?
Не понял
Здравствуйте, Tom, Вы писали:
VD>>И вообще, если TSQL так крут, то зачем тебе вообще C# сдался? Пиши все на TSQL. Tom>Ну логику обоработки данных иы и пишем на TSQL.
А что за логика еще есть в вашем приложении? Презентационная что ли?
Зачем вам тогда C#. Возмите tcl/tk, например.
Tom>Так я и не смпорбю что ВЕКТОР правильный, а реализация пока кривенькая. Вот будет DML тогда и будем переписывать.
Но вот и мы о том же. Только ждать милости от природы не в наших правилах.
Tom>Хотя для некоторых сложных запросов мы попытаемся сделать декомпозицию с помощью линка. Посмотрим насколько это реально.
ОК. Можешь обращаться за помощь. Думаю многие согласятся помочь советами в этом деле.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>А что за логика еще есть в вашем приложении? Презентационная что ли?
GUI стоят в сторонке. Они есть конечно, нескольких типов но тут не сильно много логики. Есть ещё работа с железяками, custom scripting (programmability),
VD>ОК. Можешь обращаться за помощь. Думаю многие согласятся помочь советами в этом деле.
Боюсь за@бу я всех тогда
У нас сейчас планируется первая часть рефакторинга — полное переползание на .NET (да да да, только сейчас... ((( )
будут и другие, связанные с базой. Через годик. Может тогда на рынке будут достойные решения работы с БД.
Здравствуйте, Tom, Вы писали:
Tom>А написать своё провайдер или DSL дял работы с данными так меня просто не поймут. Tom>Представь сколько усилий понадобится на поддержку и развитие этого решения. Tom>Да и работа с данными станет проще конечно но не на порядок.
Как показывает практика для некоторых задач создание специализированного под задачу ДСЛ-я позволяет упростить решение на порядки.
Дело тут в том, что реализация ДСЛ-я — это весьма механистичная работа. Задача же описанная на ДСЛ-е содержит меньше ошибок (ДСЛ можно составить так, чтобы ошибки были невозможны, или чтобы был контроль) и ее намного проще осознать (так как объем и читабельность кода при этом снижаются на порядки).
Но это если справедливо для ДСЛ-ей описывающих прикладную задачу. ДСЛ доступа к данным конечно же такого выигрыша дать не может, так как один фиг будет много другого кода.
Tom>О, тогад вопрос, есть ли смысл в linq 2 entity? Ведь это попытка как я понимаю как раз делать запросы над некой обьектной структурой.
Ключевое слово тут "entity". Entity и объект — это не одно и то же. EF ушел не туда в некоторых областях, но темнеменее его дизайн строится на основе модели данных. Я еще в 1995-ом проектировал БД с использованием EF-Win. Это такой Entity-моделлер. Поверь в EF-Win не было ни слова про объекты. Так же и в EF. Модель там от объектов не зависит. На объекты делается только отображение. А без этого никак. Ты же не можешь в ООЯ работать с понятием "запись БД"? В прочем, анонимные типы — это аналог кортежей БД. Так что... Но они и используются при работе с EF. Что плохо в EF — так это то же отсуствие поддержки DML и очень плохая поддержка функций конкретной СУБД.
Tom>>>Вот тогда всё бы стало на свои места. Пишем себе на managed языке обьекты, сохраняим их в обьектнуцю БД и выбираем данные на том же языке на котором описаны сами данные.
VD>>Ты меня извини, но я тебе скажу правду от которой ты можешь обидится, но эта действительно правда. Ты смотришь на мир глазами незнайки. ООП далеко не лучшее решение во всех случаях. Обработка данных — это как раз тот случай где ООП практически ничего путного предложить не может. Tom>А гед я спорю с этим?
Ты считаешь, что ООБД — это решение проблемы. На самом деле это такой же тупик как идеи ОР-маперов вроде Гибернэйта.
Tom>Именно по этому я не предлагаю например всякую чёрную магию в виде ORM итп... А обрабатываю данные при помощи запросов
Тогда ты уж определись. Потому что ООБД и запросы — это разные подходы.
ООП оперирует с графами объектов. Коллекции (в ООП) не являются строительной единицей. Напротив, в РСБУД коллекция является основной строительной единицей. Запросы же манипулируются с коллекциями. И именно по этому ООП и БД так плохо совмещаются.
На мой взгляд РСУБД — это самый правильный механизм хранения и обработки данны. А мапинг нужен только очень простой — строк таблиц на плоские объекты. Именно так было сделано в linq2sql. EF немного вышел за эти границы, но тем не мнее поддерживает эту парадигму. А вот ООБД и разные гибернэйты предлагают плясать от объектного графа, что и создает проблемы.
Так что без разница OR-Mappre или ООБД. Это все равно тупиковый путь.
VD>>Задумайся над тем почему ты исползуешь транзакт, а не пишешь все на С#? Или даже поставим вопрос так. Почему ты в транзакте используешь SQL? Tom>Не понял
Почему ты не используешь методы, циклы и другие атрибуты императивных языков для обрботки информации?
Почему вместо этого ты используешь запросы?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Вопрос был: сгенерирует ли твой генератор один тип для этих двух запросов, или два разных?
Генератор сгенерирует скорее метод возвращающий анонимный тип.
Здравствуйте, Tom, Вы писали:
VD>>Вопрос был: сгенерирует ли твой генератор один тип для этих двух запросов, или два разных? Tom>Генератор сгенерирует скорее метод возвращающий анонимный тип.
Гы. Анонимный тип нельзя возвратить из метода.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ключевое слово тут "entity". Entity и объект — это не одно и то же. EF ушел не туда в некоторых областях, но темнеменее его дизайн строится на основе модели данных. Я еще в 1995-ом проектировал БД с использованием EF-Win. Это такой Entity-моделлер. Поверь в EF-Win не было ни слова про объекты. Так же и в EF.
Только программка называется ER-Win, хотя работа в ней очень похожа на работу в дизайнере EF.
Здравствуйте, Tom, Вы писали:
VD>>Гы. Анонимный тип нельзя возвратить из метода. Tom>С использованием чёрной магии можно
С использованием грязных хаков.
Кстати, о причках. В Nemerle есть кортежи которые без проблем возвращаться из методов. Плюс есть локальные функции для которых есть вывод типов. Так что даже LINQ-ом и то из него проще пользоваться.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>С использованием грязных хаков.
не то что бы сильно грязных но не очень симпатишных
//
// Method that returns anonymous type as objectobject
//object ReturnAnonymous()
{
return new { City="Prague", Name="Tomas" };
}
//
// Application entry-pointv
//void Main()
{
// Get instance of anonymous type with 'City' and 'Name' propertiesobject o = ReturnAnonymous();
// This call to 'Cast' method converts first parameter (object) to the
// same type as the type of second parameter - which is in this case
// anonymous type with 'City' and 'Name'propertiesvar typed = Cast(o, new { City="", Name="" });
Console.WriteLine("Name={0}, City={1}", typed.Name, typed.City);
}
// Cast method - thanks to type inference when calling methods it
// is possible to cast object to type without knowing the type name
T Cast<T>(object obj, T type)
{
return (T)obj;
}
изврат конечно
VD>Кстати, о причках. В Nemerle есть кортежи которые без проблем возвращаться из методов. Плюс есть локальные функции для которых есть вывод типов. Так что даже LINQ-ом и то из него проще пользоваться.
Я кстате так и не понял почему анонимый тип в C# нельзя явно обьявлять. Как в других человеческих языках. (((
Здравствуйте, Tom, Вы писали:
VD>>С использованием грязных хаков. Tom>не то что бы сильно грязных но не очень симпатишных... Tom>изврат конечно
Мало того что изврат, так еще и работать будет только в пределах одной сборки.
VD>>Кстати, о причках. В Nemerle есть кортежи которые без проблем возвращаться из методов. Плюс есть локальные функции для которых есть вывод типов. Так что даже LINQ-ом и то из него проще пользоваться. Tom>Я кстате так и не понял почему анонимый тип в C# нельзя явно обьявлять. Как в других человеческих языках. (((
Наверное потому что он будет неанонимным
Наверное имеется ввиду вывод типов для возвращаемых значений методов класса.
