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

IT> Я уже упоминал, что на сегодняшний день только одна вещь, не реализуемая на LINQ — иерархические CTE. И это всё! Всё остальное делается на LINQ и сопутствующих средствах влёт.

DML? Многострочный DML? DDL? Аналитика?

IT> Есть вещи, которые, например, в linq2db пока не реализованы. Но это не вопрос невозможности, это вопрос целесообразности.

Вот и я о том же, о целесообразности.

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

IT>Нет.

У меня другое мнение.

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

IT>Конечно, буду.

Ну надо же. Хранимые процедуры позволяют тебе написать запрос один раз а затем использовать его в разных проектах. Вместо этого ты предлагаешь плодить запросы.

IT>Наличие двух приложений не означает, что они делают одно и тоже. А если это и так, то одно из них можно смело выкинуть.

Речь об одном и том же запросе а не об одном и том же приложении.

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

То есть ты хочешь сказать, что в разных приложениях не может быть одного и того же запроса?

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

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

Ты привел один частный случай в то время как я говорил об общем случае. Пример ниже.

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

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

А ты мысли не одним приложением а целой системой, группой приложений или процесов делающих что-то для бизнеса.

Я тебе приведу другой пример, встречающийся часто на практике. Какой-нибудь фронт энд показывающий кучу цифр а также репорты, предоставляющие те же самые данные. Часто бывает, что цифры они показывают разные. Начинаешь разбираться, а там один и тот же запрос в двух местах. Со временем кто-то изменил логику в одном месте а про другое забыл.

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

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

Ну так об этом и речь. Ты не понимаешь software engineering принципов ради которых создали хранимые процедуры и тупо восхваляешь LINQ, хотя он философски неверен даже в контексте одного приложения.

IT>> Есть вещи, которые, например, в linq2db пока не реализованы. Но это не вопрос невозможности, это вопрос целесообразности.

W>Вот и я о том же, о целесообразности.

Я бы вообще поставил вопрос целесообразности linq2db ибо она нарушает software engineering principles. Кто-то об этом не задумывается (включая автора), а мне, как purist-у, сложно это принять.

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

ОК>Ну надо же. Хранимые процедуры позволяют тебе написать запрос один раз а затем использовать его в разных проектах. Вместо этого ты предлагаешь плодить запросы.

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

ОК>Я тебе приведу другой пример, встречающийся часто на практике. Какой-нибудь фронт энд показывающий кучу цифр а также репорты, предоставляющие те же самые данные. Часто бывает, что цифры они показывают разные. Начинаешь разбираться, а там один и тот же запрос в двух местах. Со временем кто-то изменил логику в одном месте а про другое забыл.

Бывает и наоборот. У тебя есть хранимка и твое приложение ее использует. И вдруг при определенной версии приложения потребовалось немного изменить правила выборки в этой хранимке — сигнатура та же, логика другая. Ну поменял, все хорошо.
А через Х времени раз — и выяснилось, что этой же хранимкой иногда пользовалось какое-то совсем другое приложение (чтобы не плодить запросы), про которое все забыли, и там логика никак не должна была измениться, а теперь там все неправильно.

На мой взгляд это сложнее отловить, чем понять, почему отчет выдает неправильные данные если ведь его запрос — вот, перед глазами, а не обращение к хранимке с вводящим в заблуждением названием а-ля "spActualBuilderForThisReport" — все процедуры код дергает правильно, а на выходе фигня.

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

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

IT>> Я уже упоминал, что на сегодняшний день только одна вещь, не реализуемая на LINQ — иерархические CTE. И это всё! Всё остальное делается на LINQ и сопутствующих средствах влёт.
W>DML?

Не вопрос.

W>Многострочный DML?

Поясни.

W>DDL?

Легко.

W>Аналитика?

Первый раз слышу. Хотя нарисовать хелперов для всяких статистик и аналитик без проблем. Для этого даже не надо каких-то библиотек. Всё делается за пару минут на коленке. LINQ не об этом, а о том, чтобы SQL стал типизированным.

IT>> Есть вещи, которые, например, в linq2db пока не реализованы. Но это не вопрос невозможности, это вопрос целесообразности.
W>Вот и я о том же, о целесообразности.

Что касается целесообразности, то всяко разная фигня типа DROP TABLE сначала проверяется именно на целесообразность, а уже потом потом добавляется в библиотеку. Кстати, на очереди TRUNCATE TABLE. До сих пор обходились хелпером, но не вижу причин не добавить эту команду в библиотеку.

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

ОК>У меня другое мнение.

у тебя неверное другое мнение.

ОК>Ну надо же. Хранимые процедуры позволяют тебе написать запрос один раз а затем использовать его в разных проектах. Вместо этого ты предлагаешь плодить запросы.

Я же только что объяснял, что если у вас один запрос на несколько проектов, то у вас что-то не так с несколькими проектами.

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

Т.е у тебя несколько приложений делают одно и тоже? Может быть имеет смысл задуматься о?

IT>>Если же приложения делают разные вещи, то им нужны и разные запросы к базе данных и нет абсолютно никакого смысла пытаться городить огород из универсальных компонентов.
ОК>То есть ты хочешь сказать, что в разных приложениях не может быть одного и того же запроса?

Вполне может быть. Только здесь есть два момента. Либо мы говорим о повтоно используемых компонентах, либо мы плавно переходим к повторно используемому коду в бизнес логике.

По первому всё просто. Это должно быть реализовано ввиде повторно используемого компонента, где запрос, та-да, будет реализован один раз.
Второе — один из признаков незрелости архитектора приложения. Повторно используемая бизнелогика — это мифологема типа древние укры выкопали Чёрное море. В теории да, но на практике очень геморно. Одно из свойств бизнес логики её постоянная изменяемость. Если завтра изменятся требования к одной части приложения, исользующей общий запрос в части общего запроса, то встанет дилема — либо написать новый запрос, либо обратиться к проматери всех парадигм — флажговому программированию, т.е. трансформировать нормальный код в говно код.

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

ОК>Этот сайт — несложный и интуитивно понятный проект. Юзер это юзер, пост это пост и т.д. Более того, у меня сомнения, что этот сайт меняет, улучшает, добавляет функциональность куча программистов работающих над ним фулл-тайм. Поэтому это не удачный пример но речь не об этом.

Нормальный пример. Пафос про программирование ядерных реакторов здесь не уместен. Мне доводилось писать код для МинЮста, ГазПрома, РКА и нескольких ведущих американских банков. Архитектура всего этого при правильном подходе не принципиально отличается от этого сайта. Ты правда хочешь об этом поговорить?

ОК>Ты привел один частный случай в то время как я говорил об общем случае. Пример ниже.

Общих случаев в программировании не бывает. Точнее общий случай в программировании реализуется один единственный раз. В строительстве нельзя построить два одинаковых здания за один раз. В программировании можно.

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

ОК>А ты мысли не одним приложением а целой системой, группой приложений или процесов делающих что-то для бизнеса.

А ты сам хоть раз это пробовал? Или пока только теоретически?

ОК>Я тебе приведу другой пример, встречающийся часто на практике. Какой-нибудь фронт энд показывающий кучу цифр а также репорты, предоставляющие те же самые данные. Часто бывает, что цифры они показывают разные. Начинаешь разбираться, а там один и тот же запрос в двух местах. Со временем кто-то изменил логику в одном месте а про другое забыл.

Ещё раз, такие вещи нужно оформлять в виде повторно используемых компонентов и сервисов, а не доводить дело до базы данных и SQL.

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

Бизнес логика в базе — это анахронизм и/или вандализм. Тем более, что мне как программисту никто не запретит проигнорировать эту логику и написать свою. А база данных должна хранить и выдавать. Никаких других бизнес функций у неё быть не должно.

ОК>Ну так об этом и речь. Ты не понимаешь software engineering принципов ради которых создали хранимые процедуры и тупо восхваляешь LINQ, хотя он философски неверен даже в контексте одного приложения.

Блин, чувак, ну не стоило скатываться на персоналии. До сих пор ты производил впечатление вменяемого собеседника и вдруг нате вам — я Д'Артаньян, а вы все немытое быдло

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

ОК>Я бы вообще поставил вопрос целесообразности linq2db ибо она нарушает software engineering principles. Кто-то об этом не задумывается (включая автора), а мне, как purist-у, сложно это принять.

Ну-ка, ну-ка. Какие это ваши мягкотоварные инженерные принципы нарушает linq2db?

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

F>Именно хранимки именно для переиспользования различными несвязанными между собой приложениями — это ужасно.

Вот! Послушайте все умного человека!

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

ОК> Я бы вообще поставил вопрос целесообразности linq2db ибо она нарушает software engineering principles.

Какие именно?

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

IT> W>DML?
IT> Не вопрос.

В смысле "я все могу" или уже есть? Если последнее, то где посмотреть примеры?

IT> W>Многострочный DML?
IT> Поясни.

DML, затрагивающий несколько строк. Ну там INSERT SELECT, MERGE и т.п. Может и не стоило выделять отдельно.

IT> W>DDL?
IT> Легко.

Тот же вопрос, что и к DML. Плюс целесообразность.

IT> W>Аналитика?
IT> Первый раз слышу. Хотя нарисовать хелперов для всяких статистик и аналитик без проблем.

Я про аналитические функции.

IT> Что касается целесообразности, то всяко разная фигня типа DROP TABLE сначала проверяется именно на целесообразность, а уже потом потом добавляется в библиотеку.

Полностью согласен. Реализовывать все особенности разных диалектов, а главное, поддерживать их актуальность никто не будет.

Вопрос о целесообразности я поставил в связи с твоим заявлением про "тотальное отсутствие SQL". Если бы ты сделал оговорки, например "в нашем проекте" или "в типичном OLTP приложении", то претензий бы не было.

IT>Ну-ка, ну-ка. Какие это ваши мягкотоварные инженерные принципы нарушает linq2db?

1. Хранимки это well defined interface к базе данных.
2. В базе у тебя есть таблицы, в таблицах у тебя есть колонки, задействованны какие-то индексы и т.д. В запросах ты джойнишь таблицы, указываешь какие колонки вернуть, какие колонки как посчитать, как отсортировать result set и еще куча всего. Это implementation details. Клиентский код не должен знать как джойнятся у тебя эти самые таблицы, из каких колонок берутся значения или как они высчитываются, какие хинты ты указал и т.д. и т.п. Этого всего клиентский код знать не должен. Хинт: black box и инкапсуляция.
3. Вместо этого, linq2db и другие ORM фреймворки принуждают дублировать структуру БД в коде приложения.
4. Вместо этого, из второго пункта все эти implementation details выносятся в клиентский код. Это же самое но другими словами: такие низкоуровневые детали как таблицы, колонки, агрегатные значения, хинты выносятся выше по стэку. Это в корне неверно, хотя да, можно пользоваться linq2db и совсем не задумываться об этом.

На всякий случай приведу код из твоего блога для ясности:

using System;
using System.Linq;
 
using LinqToDB.Data;
using LinqToDB.Mapping;
 
namespace ConsoleApplication1
{
    [Table("Categories")]
    public class Category
    {
        [PrimaryKey, Identity] public int    CategoryID;
        [Column, NotNull]      public string CategoryName;
        [Column,    Nullable]  public string Description;
        [Column,    Nullable]  public byte[] Picture;
    }
 
    class Program
    {
        static void Main()
        {
            using (var db = new DataConnection())
            {
                var q =
                    from c in db.GetTable<Category>()
                    select c;
 
                foreach (var category in q)
                {
                    Console.WriteLine("ID : {0}, Name : {1}",
                        category.CategoryID,
                        category.CategoryName);
                }
            }
        }
    }
}

ОК>>Ну надо же. Хранимые процедуры позволяют тебе написать запрос один раз а затем использовать его в разных проектах. Вместо этого ты предлагаешь плодить запросы.

IT>Я же только что объяснял, что если у вас один запрос на несколько проектов, то у вас что-то не так с несколькими проектами.

Я тебе уже привел пример с фронт эндом и репортами который ты проигнорировал.

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

IT>Т.е у тебя несколько приложений делают одно и тоже? Может быть имеет смысл задуматься о?

Смотри выше. Это как в аппликейшн коде. Данные у тебя одни, а презентаций этих данных может быть много.

IT>>>Если же приложения делают разные вещи, то им нужны и разные запросы к базе данных и нет абсолютно никакого смысла пытаться городить огород из универсальных компонентов.
ОК>>То есть ты хочешь сказать, что в разных приложениях не может быть одного и того же запроса?

IT>Вполне может быть. Только здесь есть два момента. Либо мы говорим о повтоно используемых компонентах, либо мы плавно переходим к повторно используемому коду в бизнес логике.

Так "вполне может быть" или "Т.е у тебя несколько приложений делают одно и тоже? Может быть имеет смысл задуматься о?"

IT>По первому всё просто. Это должно быть реализовано ввиде повторно используемого компонента, где запрос, та-да, будет реализован один раз.

Ну и как ты сделаешь это в случае Джавы и Шарпа как я уже спросил выше?

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

Я тебе об этом и говорю.

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

ОК>>Этот сайт — несложный и интуитивно понятный проект. Юзер это юзер, пост это пост и т.д. Более того, у меня сомнения, что этот сайт меняет, улучшает, добавляет функциональность куча программистов работающих над ним фулл-тайм. Поэтому это не удачный пример но речь не об этом.

IT>Нормальный пример. Пафос про программирование ядерных реакторов здесь не уместен. Мне доводилось писать код для МинЮста, ГазПрома, РКА и нескольких ведущих американских банков. Архитектура всего этого при правильном подходе не принципиально отличается от этого сайта. Ты правда хочешь об этом поговорить?

Пафоса нету. Говорить не хочу, но мне интересно было бы узнать сколько таблиц в базе этого сайта и в базах ведущих американских банков (те базы с которыми тебе довелось поработать, то есть).

ОК>>Ты привел один частный случай в то время как я говорил об общем случае. Пример ниже.

IT>Общих случаев в программировании не бывает. Точнее общий случай в программировании реализуется один единственный раз. В строительстве нельзя построить два одинаковых здания за один раз. В программировании можно.

Что-то ты не то говоришь.

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

ОК>>А ты мысли не одним приложением а целой системой, группой приложений или процесов делающих что-то для бизнеса.

IT>А ты сам хоть раз это пробовал? Или пока только теоретически?

Довелось работать над несколькими проектами одновременно в одном отделе.

ОК>>Я тебе приведу другой пример, встречающийся часто на практике. Какой-нибудь фронт энд показывающий кучу цифр а также репорты, предоставляющие те же самые данные. Часто бывает, что цифры они показывают разные. Начинаешь разбираться, а там один и тот же запрос в двух местах. Со временем кто-то изменил логику в одном месте а про другое забыл.

IT>Ещё раз, такие вещи нужно оформлять в виде повторно используемых компонентов и сервисов, а не доводить дело до базы данных и SQL.

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

Ну и ты не можешь плодить сервисы на каждый чих.

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

IT>Бизнес логика в базе — это анахронизм и/или вандализм. Тем более, что мне как программисту никто не запретит проигнорировать эту логику и написать свою. А база данных должна хранить и выдавать. Никаких других бизнес функций у неё быть не должно.

Возьми обычный селект. Один селект. Его джойны, его колонки, его условия — эти AND и OR — а также порядок в котором возвращаются ряды это уже и есть бизнес логика. От этого ты никуда не уйдешь.

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

ОК>>Ну так об этом и речь. Ты не понимаешь software engineering принципов ради которых создали хранимые процедуры и тупо восхваляешь LINQ, хотя он философски неверен даже в контексте одного приложения.

IT>Блин, чувак, ну не стоило скатываться на персоналии. До сих пор ты производил впечатление вменяемого собеседника и вдруг нате вам — я Д'Артаньян, а вы все немытое быдло

Слушай, я не скатывался. Вот без лести тебе скажу, что считаю тебя одним из немногих профи на этом сайте. Но и на старуху бывает проруха. Я не согласен с некоторыми твоими утверждениями и не хочу быть политкорректным.

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

W>В смысле "я все могу" или уже есть? Если последнее, то где посмотреть примеры?

http://blog.linq2db.com/2015/05/linq-crud-operations.html

W>DML, затрагивающий несколько строк. Ну там INSERT SELECT, MERGE и т.п. Может и не стоило выделять отдельно.

Там же.

W>Я про аналитические функции.

Типа PERCENT_RANK? В наличии нет, но легко делаются с помощью стандартных расширений буквально в 5 строчек кода.

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

ОК>1. Хранимки это well defined interface к базе данных.

Во-первых, хранимки — это the worst practices ever. Регулярно попадаются люди, у которых от передозировки хранимками случилась на них стойка аллергия. У меня тоже в своё время был неслабый передоз, так что о предмете я имею весьма солидные познания. Но в отличии от многих спроки мне знакомы не только с хорошей стороны, но и с плохой.

Во-вторых, видимо ты не совсем понимаешь, что такое бизнес логика и какими свойствами она должна обладать. Объясняю.

Существуют два принципиально оличающихся друг от друга типа кода. Назовём их условно System.String и GetCustomerByID. Разница между этими двумя типами кода в том, что к ним применяются принципиально разные требования.

System.String должен иметь стабильный хорошо продуманный интерфейс, быть сомодостаточным, отвечать самым требовальным запросам производительности. Плата за это как правило всестороннее маниакальное тестирование, нечеловеческие человеко-часы либо изрядно попахивающий код внутри. Такой код пишется один раз навека и в дальнейшем в лучшем случае несильно расширяется, но почти никогда не меняется, т.к. это может легко привести к ломке использующего его кода.

Главное требование к GetCustomerByID — это гибкость такого код. Такой код должен быть всегда готов к изменению. Завтра ко мне придёт BA и скажет, что вот здесь вот этот фактор надо бы ещё домножить на вот это число из вот этой таблицы и я должен буду быстро и, главное, не ломая ничего вокруг внести изменения. При этом у меня могут поплыть все запросы в БД. Если я начну говорить о том, что этого сделать нельзя потому что у меня уже "well defined interface к базе данных" и его ломать никак нельзя, то на меня будут смотреть либо как на идиота, либо вообще уволят и будут правы. Главное качаество бизнес кода — это возможность его быстро менять под новые требования, причём так, чтобы после этих изменений он оставался готовым к новым.

Сохранённые процедуры убивают гибкость кода на корню. Ещё один, хоть и менее разрушительный способ — это повторное использование кода в бизнес логике. Ты предлагаешь сразу два в одном флаконе. Что ж, поздравляю, ты породил ещё одного Франкенштейна. Худшего способа навредить проекту не существует.

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

ОК>2. В базе у тебя есть таблицы, в таблицах у тебя есть колонки, задействованны какие-то индексы и т.д. В запросах ты джойнишь таблицы, указываешь какие колонки вернуть, какие колонки как посчитать, как отсортировать result set и еще куча всего. Это implementation details.

Это — бизнес логика, дружище. Это — бизнес логика. Как отсортировать и куча всего должны быть прописаны в спеке. То, что ты называешь implementation details напрямую зависят от бизнес требований. Изменились требования — изменились implementation details.

ОК>Клиентский код не должен знать как джойнятся у тебя эти самые таблицы, из каких колонок берутся значения или как они высчитываются, какие хинты ты указал и т.д. и т.п. Этого всего клиентский код знать не должен. Хинт: black box и инкапсуляция.

Какая чушь? Что ещё за клиентский код? Если ты про восемнадцатый слой в своей слоёной архитектуре, то ты ещё более безнадёжен, чем я думал. Но даже в этом случае никто не запрещает именно в твоём DAL использовать LINQ и скрывать детали как угодно. Или ты хочешь сказать, что детали можно скрыть только в сохранённых процедурах?

ОК>3. Вместо этого, linq2db и другие ORM фреймворки принуждают дублировать структуру БД в коде приложения.

Каша в голове — это невкусно. Конвертировать стуктуру БД в термины приложения не нужно только в одном случае — если твой клиентский код непосредственно обращается к ридеру запроса. DAL как концепция был придуман как раз как изолятор подобных действий от остального приложения и в нём, если ты ещё не понял, как раз и осуществляется дублирование/преобразование терминов (структуры) базы данных в термины приложения. В linq2db это делается немного в другом месте, вот и вся разница.

ОК>4. Вместо этого, из второго пункта все эти implementation details выносятся в клиентский код. Это же самое но другими словами: такие низкоуровневые детали как таблицы, колонки, агрегатные значения, хинты выносятся выше по стэку. Это в корне неверно, хотя да, можно пользоваться linq2db и совсем не задумываться об этом.

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

Задача DAL изолировать работу с базой данных от остальной части приложения путём перевода терминов БД в термины приложения и наоборот. Никаких других функций у него в идеале быть не должно, но к сожалению, бизнес логика всё же просачивается в DAL в виде тех же сортировок, группировок и пейджингов. У DAL есть ещё одна функция – как раз та самая слоёность. Но это не уникальное качество DAL, а просто часть многослойной архитектуры.

Первую функцию DAL – изоляцию, LINQ выполняет другим, на мой взгляд более изящным способом – генерацией или описанием всей структуры БД в отдельном месте. Как раз в этом месте происходит перевод терминов БД в термины приложения. Вторая функция – слоёность, как мы уже выяснили, может использоваться с любыми инструментами, в том числе и с LINQ.

Теперь поговорим о слоёности. В своё время я её очень сильно продвигал в том числе и на этом сайте. Но потом я от неё устал. Приходится писать слишком много никому не нужного бестолкового кода типа пустышек pass through методов. К тому же тотальное выделение бизнес логики в отдельный слой провоцировало к повторному использованию этого бизнес кода, что часто приводило превращению такого кода в кашу. Сценарий такого превращения очень прост. При изменении бизнес требований к одному из методов, использующих наш повторно используемый код, встаёт необходимость, например, в дополнительном условии. Такое условие передаётся, например, как дополнительный параметр и в повторно используемом методе появляется дополнительный if. Со временем такой метод обрастает такими условиями и флажками как собака блохами. Учитывая, что вызывающие методы в процессе изменения приложения вообще могут со временем отмирать, то понять, что реально происходит в таких методах со временем становится очень и очень нетривиально.

В общем, от слоя бизнес логики я постепенно отказался, заменяя реально необходимое повторное использование не в слои, а в сервисы/компоненты. Когда же появился LINQ, то последний слой – DAL, был с радостью выброшен, и многослойная архитектура со всеми её анахронизмами окончательно ушла из моей жизни.

ОК>На всякий случай приведу код из твоего блога для ясности:

Это пример, демонстрирующий использование библиотеки, но ты сделал по нему вывод о моих архитектурных предпочтениях. Ну-ну.

ЗЫ. Предыдущий ответ почему отправился недописанным самопроизвольно.

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

ОК>Я тебе уже привел пример с фронт эндом и репортами который ты проигнорировал.

Не могу найти, где я это проигнорировал.

IT>>Т.е у тебя несколько приложений делают одно и тоже? Может быть имеет смысл задуматься о?
ОК>Смотри выше. Это как в аппликейшн коде. Данные у тебя одни, а презентаций этих данных может быть много.

Это очередное заблуждение, которое красиво выглядит только в теории. На практике никакх много презентаций одних и тех же данных не бывает. Любая презентация, если она не полная копия предыдущей требует данные хотя бы чуть-чуть, но в другом виде.

IT>>Вполне может быть. Только здесь есть два момента. Либо мы говорим о повтоно используемых компонентах, либо мы плавно переходим к повторно используемому коду в бизнес логике.
ОК>Так "вполне может быть" или "Т.е у тебя несколько приложений делают одно и тоже? Может быть имеет смысл задуматься о?"

Ещё раз. Вполне может быть. Только здесь есть два момента. Либо мы говорим о повтоно используемых компонентах, либо мы плавно переходим к повторно используемому коду в бизнес логике.

IT>>По первому всё просто. Это должно быть реализовано ввиде повторно используемого компонента, где запрос, та-да, будет реализован один раз.
ОК>Ну и как ты сделаешь это в случае Джавы и Шарпа как я уже спросил выше?

Да никак. Джаве — джавово, шарпу шарпово. С вероятностью где-то в 100% двум разным приложениям, делающим разные вещи понадобятся совершенно разные запросы. Если же им потребуется результат работы одного сервиса, то это и должен быть один сервис. Клепать сервисы с помощью спроков, наверное можно, но это уже из серии садомазо. Это не ко мне.

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

ОК>Я тебе об этом и говорю.

Сохранённых процедур это касается в полной мере.

ОК>Пафоса нету. Говорить не хочу, но мне интересно было бы узнать сколько таблиц в базе этого сайта и в базах ведущих американских банков (те базы с которыми тебе довелось поработать, то есть).

На сайте где-то с полсотни. В обычном приложении около сотни двух, видел и больше. Тенденция очень простая — чем хуже дизайн, тем больше в приложении таблиц. Но меня количество таблиц как-то не особо смущает. Сколько надо, столько пусть и будет. К чему это ты вообще?

ОК>Довелось работать над несколькими проектами одновременно в одном отделе.

И? Мне доводилось работать над несколькими проектами в одной команде. Даже во мне самом. В чём проблема?

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

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

ОК>Ну и ты не можешь плодить сервисы на каждый чих.

Пложу ровно столько сколько мне нужно, но гораздо меньше, чем ты думаешь.

ОК>Я согласен что БД должна возвращать данные а презентацией должен заниматься клиентский код, но позволю себе расширить твое утверждение. То что естественно для базы должно делаться на базе. Остальное — выше по стэку.

Ну наконец-то.

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

IT> W>В смысле "я все могу" или уже есть? Если последнее, то где посмотреть примеры?

IT> http://blog.linq2db.com/2015/05/linq-crud-operations.html

Спасибо.
А почему везде литералы, а не параметры?

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

IT> Сервисы в БД — это мазохизм. Ни отладчика, ни средств навигации по коду, ни средств рефакторинга. Некоторые базы типа Sybase вообще теряют контекст, если вызвать из одной процедуры другую. Языковые средства стары как какашки мамонта. Сам язык нетипизированный, пиши что хочешь, а потом лови в рантайме, если повезёт создать удачный сценарий. Можно легко грохнуть или переименовать таблицу и никто этого не заметит до падения системы в продакшине.

Опять-таки, делай оговорку про личный опыт.

ОК>>1. Хранимки это well defined interface к базе данных.

IT>Во-первых, хранимки — это the worst practices ever.

Это с твоей точки зрения.

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

То есть ты считаешь, что только ты один имеешь представление о предмете?

Я соглашусь с тобой, что хранимки не без проблем, но это философски самое правильное решение, нравится оно тебе или нет.

IT>Во-вторых, видимо ты не совсем понимаешь, что такое бизнес логика и какими свойствами она должна обладать. Объясняю.

Не глупее тебя. Прекрасно понимаю.

IT>Существуют два принципиально оличающихся друг от друга типа кода. Назовём их условно System.String и GetCustomerByID. Разница между этими двумя типами кода в том, что к ним применяются принципиально разные требования.

К чему отходить от темы?

IT>System.String должен иметь стабильный хорошо продуманный интерфейс, быть сомодостаточным, отвечать самым требовальным запросам производительности. Плата за это как правило всестороннее маниакальное тестирование, нечеловеческие человеко-часы либо изрядно попахивающий код внутри. Такой код пишется один раз навека и в дальнейшем в лучшем случае несильно расширяется, но почти никогда не меняется, т.к. это может легко привести к ломке использующего его кода.

Спасибо за просвещение но данный параграф только отвлекает от дискуссии.

IT>Главное требование к GetCustomerByID — это гибкость такого код. Такой код должен быть всегда готов к изменению. Завтра ко мне придёт BA и скажет, что вот здесь вот этот фактор надо бы ещё домножить на вот это число из вот этой таблицы и я должен буду быстро и, главное, не ломая ничего вокруг внести изменения. При этом у меня могут поплыть все запросы в БД. Если я начну говорить о том, что этого сделать нельзя потому что у меня уже "well defined interface к базе данных" и его ломать никак нельзя, то на меня будут смотреть либо как на идиота, либо вообще уволят и будут правы. Главное качаество бизнес кода — это возможность его быстро менять под новые требования, причём так, чтобы после этих изменений он оставался готовым к новым.

Опять-таки, ты не понял сказанного. Разумеется если тебе надо изменить интерфейс чтобы решить бизнес задачу, ты волен это сделать. Говоря что хранимки это well defined interface к базе данных, я имел в виду, что это единственные "точки входы" через которые ты можешь что-то получить от базы.

В Си Шарповском коде у тебя есть объекты. Ты можешь вызвать какое-то множество публичных методов на этом объекте. Другой пример: у тебя есть веб сервис. У него тоже есть какое-то определенное количество методов. Аналогичным образом и БД. Только через хранимки ты можешь что-то получить из нее. Для клиентского кода каждый из этих "объектов" (обычный си шарповский объект, веб сервис и база) черный ящик.

IT>Сохранённые процедуры убивают гибкость кода на корню.

У сиквела есть проблемы. Поэтому хранимые процедуры тоже не без проблем, но, повторюсь, философски они самое правильное решение, нравится оно тебе или нет.

IT>Ещё один, хоть и менее разрушительный способ — это повторное использование кода в бизнес логике. Ты предлагаешь сразу два в одном флаконе. Что ж, поздравляю, ты породил ещё одного Франкенштейна. Худшего способа навредить проекту не существует.

Я что-то не понял, что я предлагаю согласно тебе.

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

Ты ловко уходишь все дальше и дальше от вопроса.

ОК>>2. В базе у тебя есть таблицы, в таблицах у тебя есть колонки, задействованны какие-то индексы и т.д. В запросах ты джойнишь таблицы, указываешь какие колонки вернуть, какие колонки как посчитать, как отсортировать result set и еще куча всего. Это implementation details.

IT>Это — бизнес логика, дружище. Это — бизнес логика. Как отсортировать и куча всего должны быть прописаны в спеке. То, что ты называешь implementation details напрямую зависят от бизнес требований. Изменились требования — изменились implementation details.

Дружище, так это я тебе в ветке ниже и сказал с примером про один селект. Но смысл этого твоего комментария так и не ясен. Разумеется implementation details напрямую зависят от бизнес требований. Тут вопрос в другом — где в стэке должны находиться эти implementation details.

ОК>>Клиентский код не должен знать как джойнятся у тебя эти самые таблицы, из каких колонок берутся значения или как они высчитываются, какие хинты ты указал и т.д. и т.п. Этого всего клиентский код знать не должен. Хинт: black box и инкапсуляция.

IT>Какая чушь?

Чушь это ты говоришь.

IT>Что ещё за клиентский код?

Ну а какой еще код работает с базой данных?

IT>Если ты про восемнадцатый слой в своей слоёной архитектуре, то ты ещё более безнадёжен, чем я думал.

Это уже твои фантазии про восемнадцатый слой.

IT>Но даже в этом случае никто не запрещает именно в твоём DAL использовать LINQ и скрывать детали как угодно.

Разумеется никто не запрещает.

IT>Или ты хочешь сказать, что детали можно скрыть только в сохранённых процедурах?

Нет, нет и еще раз нет! Детали можно скрыть где угодно, но философски/идеологически детали правильно скрыть в хранимых процедурах. Вот это я говорю. Почему — я объяснил в посте не который ты сейчас ответил.

ОК>>3. Вместо этого, linq2db и другие ORM фреймворки принуждают дублировать структуру БД в коде приложения.

IT>Каша в голове — это невкусно. Конвертировать стуктуру БД в термины приложения не нужно только в одном случае — если твой клиентский код непосредственно обращается к ридеру запроса. DAL как концепция был придуман как раз как изолятор подобных действий от остального приложения и в нём, если ты ещё не понял, как раз и осуществляется дублирование/преобразование терминов (структуры) базы данных в термины приложения. В linq2db это делается немного в другом месте, вот и вся разница.

Это у тебя каша в голове. Пока что я не увидел ни одного четкого комментария на мой пост выше, а только какое-то либо действительно непонимание либо желание запутать читающего.

ОК>>4. Вместо этого, из второго пункта все эти implementation details выносятся в клиентский код. Это же самое но другими словами: такие низкоуровневые детали как таблицы, колонки, агрегатные значения, хинты выносятся выше по стэку. Это в корне неверно, хотя да, можно пользоваться linq2db и совсем не задумываться об этом.

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

Не перепутал. Имхо это ты умышленно запутываешь читающих.

IT>Задача DAL изолировать работу с базой данных от остальной части приложения путём перевода терминов БД в термины приложения и наоборот. Никаких других функций у него в идеале быть не должно, но к сожалению, бизнес логика всё же просачивается в DAL в виде тех же сортировок, группировок и пейджингов. У DAL есть ещё одна функция – как раз та самая слоёность. Но это не уникальное качество DAL, а просто часть многослойной архитектуры.

Может ты прекратишь разговаривать со мной как с пятилетним?

IT>Первую функцию DAL – изоляцию, LINQ выполняет другим, на мой взгляд более изящным способом – генерацией или описанием всей структуры БД в отдельном месте. Как раз в этом месте происходит перевод терминов БД в термины приложения. Вторая функция – слоёность, как мы уже выяснили, может использоваться с любыми инструментами, в том числе и с LINQ.

IT>Теперь поговорим о слоёности. В своё время я её очень сильно продвигал в том числе и на этом сайте. Но потом я от неё устал. Приходится писать слишком много никому не нужного бестолкового кода типа пустышек pass through методов. К тому же тотальное выделение бизнес логики в отдельный слой провоцировало к повторному использованию этого бизнес кода, что часто приводило превращению такого кода в кашу. Сценарий такого превращения очень прост. При изменении бизнес требований к одному из методов, использующих наш повторно используемый код, встаёт необходимость, например, в дополнительном условии. Такое условие передаётся, например, как дополнительный параметр и в повторно используемом методе появляется дополнительный if. Со временем такой метод обрастает такими условиями и флажками как собака блохами. Учитывая, что вызывающие методы в процессе изменения приложения вообще могут со временем отмирать, то понять, что реально происходит в таких методах со временем становится очень и очень нетривиально.

Опять ответ не по делу.

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

Я могу только порадоваться за тебя, но ничего по делу я в твоем ответе не прочитал.

ОК>>На всякий случай приведу код из твоего блога для ясности:

IT>Это пример, демонстрирующий использование библиотеки, но ты сделал по нему вывод о моих архитектурных предпочтениях. Ну-ну.

Об архитектуре речь вообще не шла. Я показал код который нарушает инкапсуляцию базы данных (а именно дублирование таблиц в Си шарповском коде и запрос который знает о структуре базе данных).

IT>ЗЫ. Предыдущий ответ почему отправился недописанным самопроизвольно.

Какой ответ?

Слушай, я задам тебе два вопроса. Постараюсь их изложить максимально просто. Постарайся ответить на них без этих растеканий по дереву.

Итак, на нижнем уровне стэка у тебя есть база, язык которой SQL. Уровнем выше у тебя код на Си шарпе. Теперь вопросы.

1. Почему код на Си шарпе должен знать implementation details нижележащего уровня (структура БД)?
2. Почему код на Си шарпе лезет во внутренности нижележащего уровня (запросы)?

On 14.09.2015 09:53, "Олег К." wrote:

> Я соглашусь с тобой, что хранимки не без проблем, но это *философски*
> самое правильное решение, нравится оно тебе или нет.

"Суха, мой друг, теория везде, А древо жизни пышно зеленеет." (с)

О большинстве проектов, в которых хранимки декларировались как
"единственные "точки входы" через которые ты можешь что-то получить от
базы" у меня лично остались крайне неприятные воспоминания. Попытки
выразить бизнес-логику убогими средствами PL/SQL (T-SQL, etc.)
которые я видел лично — калечны и непродуктивны, создают
значительные проблемы в развитии проекта, вообщем создают больше
практических проблем чем наносят философской пользы.
Возможно, впрочем, что где-то и существуют хрустальные дворцы на холмах.

--
WBR,
Serge.

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

IT>> Сервисы в БД — это мазохизм. Ни отладчика, ни средств навигации по коду, ни средств рефакторинга. Некоторые базы типа Sybase вообще теряют контекст, если вызвать из одной процедуры другую. Языковые средства стары как какашки мамонта. Сам язык нетипизированный, пиши что хочешь, а потом лови в рантайме, если повезёт создать удачный сценарий. Можно легко грохнуть или переименовать таблицу и никто этого не заметит до падения системы в продакшине.

W>Опять-таки, делай оговорку про личный опыт.

Это само собой. Есть только одно маленькое дополнение. Мой опыт включает как интенсивное использование сохранённых процедур и прямого SQL, так и не менее интенсивное использование LINQ. Я могу вполне объективно сравнивать.