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

C>А как всегда, сначала секанули, а затем отращивают.

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

C>В любом случае OData неплохо развивается,

Она не может неплохо развиваться, будучи с рождения ограниченной в рамках GET запроса браузера. Примитивные запросы — вполне, запросы к подготовленным методам на сервере — тоже возможно. Но говорить о каком-то серьёзном использовании OData в энтерпрайз приложениях — это вульгарный мазохизм.

C>в отличии от LINQ (твою привязанность к LINQ понять могу, здорово было сделано, но только для .NET/MSSQL).

Думаю, здесь есть определённое недопонимание. Когда я говорю о LINQ, то я не имею ввиду LINQ to SQL и даже EF. Первый скорее мёртв, чем жив. Это правда. Второй никак не попадёт в какие-нибудь приличные руки и мозги, что бы из него сделали более менее путный инструмент.

Я говорю о LINQ как о технологии вообще и о linq2db в частности. С этим всем как раз всё в порядке. Развитие идёт своим чередом. Последний релиз был на днях. Количеству поддерживаемых баз данных может позавидовать не только любой LINQ провайдер включая EF, но и любой database tool, претендующий на поддержку нескольких БД. В моём проекте linq2db используется для работы с SqlServer, DB2/zOS и Oracle. Полёт нормальный. В наличии, кроме традиционных возможностей LINQ, поддержка DDL и DML, BulkCopy из коробки и прочие вкусности. В нашем проекте код, приведённый ниже, в порядке вещей:

var tempIDs = db.CreateTable<ID>();

tempIDs.BulkCopy(new[] {1, 2, 3, .....})

var q =
    from t in db.Table1
    join id in tempIDs on t.ID equals id.ID
    ...

Т.е. в наличии не только примитивные селекты, но и полный набор работы с временными таблицами, инсёртами, делитами и т.п. Есдинственное чего мы пока не умеем — это рекурсивные CTE и то по причине невозможности их выразить в C#. В остальном у нас по сути типизированный SQL интегрированный в C# со всеми вытекающими.

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

S>Hi, All!


S>Вопрос: а какой сейчас есть мейнстримовый путь работы с базами данных? Ну, например, из MSVisualC или из любого другого средства разработки "общего характера"?

Все БД уже давно крутятся на разных юниксах, а под виндой бд мало кому нужны

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

Z>Все БД уже давно крутятся на разных юниксах, а под виндой бд мало кому нужны

Да хоть на mainframe. Главное — где клиент.

> Да хоть на mainframe. Главное — где клиент.

на вэбе

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

>> Да хоть на mainframe. Главное — где клиент.
AC>на вэбе

Клиент базы данных не вебе? Это что-то новое в дизайне приложений. Особенно в части защиты доступа к данным. Даже SQL injection не нужен. Просто бери и грохай пользуйся.

> Клиент базы данных не вебе? Это что-то новое в дизайне приложений. Особенно в части защиты доступа к данным.
> Даже SQL injection не нужен. Просто бери и грохай пользуйся

Как же бедный и несчастный rsdn.ru всё ещё жив...
Или он уже перестал жить в BD?

кстати, почему не работает форматирование сообщений?

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

AC>Как же бедный и несчастный rsdn.ru всё ещё жив...

Клиент базы данных RSDN нааходится на сервере, а не в вебе. В вебе находится клиент самого RSDN.

AC>кстати, почему не работает форматирование сообщений?

Да вроде всё работает.

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

C>>В любом случае OData неплохо развивается,

IT>Она не может неплохо развиваться, будучи с рождения ограниченной в рамках GET запроса браузера. Примитивные запросы — вполне, запросы к подготовленным методам на сервере — тоже возможно. Но говорить о каком-то серьёзном использовании OData в энтерпрайз приложениях — это вульгарный мазохизм.

То что OData работает в основном в рамках GET запросов это скорее плюс чем ограничение. Серверная часть — отдельная задача. Она легко тестируется в том числе на безопасность. Сложные запросы действительно придется готовить на сервере, но это тоже скорее плюс. Навредить такой базе данных извне будет сложнее.

В общем можно и нужно говорить о серьёзном использовании.

Здравствуйте, Аноним, Вы писали:

А>В общем можно и нужно говорить о серьёзном использовании.

Именно. Если говорить о серьёзном использовании, то работа с сервером у большинства WPF/SL девелоперов это одна из самых больших попаболей. Особенно, если они используют веб-сервисы. OData часть этой боли слегка снимает, но т.к. это не лечение болезни, а всего лишь болеутоляющее, то после превыкания попе всё равно по прежнему очень больно. В результате, если есть возможность народ переходит назад к двух звенке. Либо использует LINQ over WCF , в котором все ограничения OData сняты.

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

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

Если одни разрабатывают серверную часть, другие клиентскую, третьи web решение, четвертые делают анализ данных через Excel, то даже мысли переходить назад к двухзвенке не появится. OData для такой архитектуры. WCF тоже, но сегодня явно уступает по возможностям.

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

C>Если одни разрабатывают серверную часть, другие клиентскую, третьи web решение, четвертые делают анализ данных через Excel, то даже мысли переходить назад к двухзвенке не появится.

А мужики то и не знают
Проблема двухзвенки в энтерпрайзе ровно одна — при большом количестве клиентов к серверу БД может быть открыто слишком много соединений, которые не являются для сервера БД бесплатным ресурсом. Самому же коду без разницы где работать — на сервере приложений или на машине клиента.

C>OData для такой архитектуры. WCF тоже, но сегодня явно уступает по возможностям.

Я не против этой философемы. Для этого они подходят. Не самым лучшим образом, но если регулярно принимать обезболивающее, то подходят. Чистое решение, снимающее вообще все проблемы присущие OData — это LINQ over WCF, реализованный в BLToolkit и linq2db.

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

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

Вот именно, я изначально писал только про глобальное решение.

IT>Самому же коду без разницы где работать — на сервере приложений или на машине клиента.

Не нужно глобальное решение -- флаг в руки. Но баги выгребать будет сложенее.

C>>OData для такой архитектуры. WCF тоже, но сегодня явно уступает по возможностям.

IT>Я не против этой философемы. Для этого они подходят. Не самым лучшим образом, но если регулярно принимать обезболивающее, то подходят. Чистое решение, снимающее вообще все проблемы присущие OData — это LINQ over WCF, реализованный в BLToolkit и linq2db.

Ага! Зоопарк решений исключительно для .NET.

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

IT>>Самому же коду без разницы где работать — на сервере приложений или на машине клиента.
C>Не нужно глобальное решение -- флаг в руки. Но баги выгребать будет сложенее.

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

C>Ага! Зоопарк решений исключительно для .NET.

Ой, только не надо свои домыслы возводить в ранг истины. Как раз на .NET стало впервые возможным полноценное использование типизированного SQL со всеми последствиями. Например, для меня теперь словосочетание рефакторинг базы данных стало вполне привычным. Нужно только следовать двум правилам: использовать LINQ вместо прямого SQL и не использовать сохранённых процедур.

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

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

IT>>>Самому же коду без разницы где работать — на сервере приложений или на машине клиента.
C>>Не нужно глобальное решение -- флаг в руки. Но баги выгребать будет сложенее.

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

Может и странное, но по моему глобальность это точно про переносимость кода, а про доступность и защищённость данных.

C>>Ага! Зоопарк решений исключительно для .NET.

IT>Ой, только не надо свои домыслы возводить в ранг истины.

Никаких домыслов, только факт что эти решения на платформе .NET.

IT>Как раз на .NET стало впервые возможным полноценное использование типизированного SQL со всеми последствиями. Например, для меня теперь словосочетание рефакторинг базы данных стало вполне привычным. Нужно только следовать двум правилам: использовать LINQ вместо прямого SQL и не использовать сохранённых процедур.

Я уже писал что не имею ничего против LINQ, но стоит ли изучать ее сейчас или все же лучше уделить внимание другим технологиям?

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

C>Я уже писал что не имею ничего против LINQ, но стоит ли изучать ее сейчас или все же лучше уделить внимание другим технологиям?

Linq в его общем смысле стоило изучать еще в 2007/2008 году, и конечно же и сейчас. Если говорить о конкретно разных проектах linq to databases (linq2sql, EF, linq2db), то видимо это зависит от конкретного проекта на работе. Лично на всех моих последних проектах linq2db вписывался отлично, и я сейчас боюсь представить если вдруг придется работать без него.

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

C>Может и странное, но по моему глобальность это точно про переносимость кода, а про доступность и защищённость данных.

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

C>Я уже писал что не имею ничего против LINQ, но стоит ли изучать ее сейчас или все же лучше уделить внимание другим технологиям?

Это зависит от задач и предпочтений. Для моих задач эта технология является настолько ключевой, что без её знания или хотя бы приличного представления о ней мы не принимаем людей на работу.

Кстати, многие даже работая ранее с LINQ, воспринимают тотальное отсутствие SQL с недоверием, а те, кто раньше пользовал EF, даже с неприятием. Но потом на других проектах испытывают без этого неудержимую ностальгию.

IT>Ой, только не надо свои домыслы возводить в ранг истины.

А ты разве не это же самое делаешь?

IT>Как раз на .NET стало впервые возможным полноценное использование типизированного SQL со всеми последствиями. Например, для меня теперь словосочетание рефакторинг базы данных стало вполне привычным. Нужно только следовать двум правилам: использовать LINQ вместо прямого SQL и не использовать сохранённых процедур.

На счет последнего предложения. Представь что у тебя два проекта. Один на .НЕТ-е, другой на Джаве. И нужен этим приложениям один и тот же запрос. Будешь плодить запросы на разных технологиях?

А если три проекта или даже больше? Напомню, что в энерпрайзе с БД могут работать много разных приложений.

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

IT> Кстати, многие даже работая ранее с LINQ, воспринимают тотальное отсутствие SQL с недоверием, а те, кто раньше пользовал EF, даже с неприятием. Но потом на других проектах испытывают без этого неудержимую ностальгию.

Но все же не будем забывать, что LINQ на сегодняшний день реализует лишь подмножество SQL и его диалектов. Поэтому о "тотальном отсутствии" в серьезных проектах говорить не приходится. И, я полагаю, в будущем это так и останется. Кесарю — кесарево.

Здравствуйте, Олег К., Вы писали:

ОК>А ты разве не это же самое делаешь?

Нет.

ОК>На счет последнего предложения. Представь что у тебя два проекта. Один на .НЕТ-е, другой на Джаве. И нужен этим приложениям один и тот же запрос. Будешь плодить запросы на разных технологиях?

Конечно, буду. Наличие двух приложений не означает, что они делают одно и тоже. А если это и так, то одно из них можно смело выкинуть. Если же приложения делают разные вещи, то им нужны и разные запросы к базе данных и нет абсолютно никакого смысла пытаться городить огород из универсальных компонентов. Всё это проходили уже тысячу раз. Даже на этом сайте есть три клиента, которые ходят в базу данных: web, janus, nntp. У всех не просто разные запросы, у всех даже структура и принципы выборки данных разные. Более того, т.к. сайт существует уже 15 лет, то здесь хоть и нет джавы, но наслоений технологий хватает. В том числе часть запросов написана на SQL, часть на LINQ. И никаких особых затруднений это не вызывает.

ОК>А если три проекта или даже больше? Напомню, что в энерпрайзе с БД могут работать много разных приложений.

Да хоть сколько. Я вообще не очень понимаю этого вопроса. Как наличие нескольких приложений могут повлиять на дизайн одного из них? Ну вот есть у нас на работе внешная Oracle БД, к которой нам дали доступ и из которой мы периодически черпаем данные. Я даже понятия не имею какие там есть ещё клиенты и на чём они написаны. Тем более, ни их число, ни их технологии на мой дизайн не могут повлиять никак.

В общем, в чём суть претензий не понятно

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

W>Но все же не будем забывать, что LINQ на сегодняшний день реализует лишь подмножество SQL и его диалектов. Поэтому о "тотальном отсутствии" в серьезных проектах говорить не приходится. И, я полагаю, в будущем это так и останется. Кесарю — кесарево.

Я уже упоминал, что на сегодняшний день только одна вещь, не реализуемая на LINQ — иерархические CTE. И это всё! Всё остальное делается на LINQ и сопутствующих средствах влёт. Есть вещи, которые, например, в linq2db пока не реализованы. Но это не вопрос невозможности, это вопрос целесообразности. Понадобились в том же Oracle xml-таблицы — получите xml-таблицы. Понадобились в DB2 хинты, уровня запроса — получите хинты. Сделать можно всё. Даже тот же иерархический CTE не сделан только лишь потому, что пока не придумали как его выразить на C#.