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

W>А почему везде литералы, а не параметры?

Потому что в исходном коде литералы, а не параметры. Что написал, то и получил. Есть ещё дополнительный параметр, который все параметры генерирует как литералы. Полезен для отладдки, особенно на серверах, где объявить переменную прямо в тексте запроса нельзя.

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

H>О большинстве проектов, в которых хранимки декларировались как "единственные "точки входы" через которые ты можешь что-то получить от базы" у меня лично остались крайне неприятные воспоминания.

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

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

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

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

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

1) Инкапсуляция
2) Хранимые процедуры vs Linq

По поводу инкапсуляции. Во-первых, как уже упоминалось, всякие сортировки и пейджинги — это не implementation details, это бизнес-логика. Во-вторых, никто лично вам не мешает выделить DAL для повышения инкапсуляции, структуризации, повторного использования. На позапрошлом проекте я так и делал, использовал linq2db, но при этом по-старинке выделял DAL. Если вы хотите, чтобы одинаковые запросы выполнялись на разных клиентах — пожалуйста, можно сделать веб-сервис, который внутри будет использовать linq. Кстати, то "нарушение инкапсуляции" здесь очень сильно играет на руку в плане рефакторинга и find usages.

По поводу Хранимых процедур vs Linq.
Я примерно 9 лет работал с хранимыми процедурами. Последние годы работаю с linq2db. Т.е. сравнить могу.
У хранимых процедур на мой взгляд две основные проблемы — отладка и рефакторинг. И если с отладкой еще можно примириться, благо некоторые IDE предоставляют отладку хранимых процедур, то рефакторинг становится либо невозможным, либо превращается в кошмар и вылезающие в run-time баги.
Хранимые процедуры, на мой взгляд, должны использовать только тогда, когда они совершенно необходимы, в каких-то конкретных частях проекта, но не как основной инсрумент работы с БД.

Когда я думаю о том, что в будущем я могу попасть на проект, где вся работа с БД опять будет на хранимых процедурах, у меня по рукам пробегают мурашки.

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

ОК>>>1. Хранимки это well defined interface к базе данных.
IT>>Во-первых, хранимки — это the worst practices ever.
ОК>Это с твоей точки зрения.

Так и предыдущее исключительно твоё умозаключение.

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

Не только. Я ещё имею представление и о LINQ, т.е. о двух предметах, которые обсуждаются в этом топике.

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

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

ОК>К чему отходить от темы?
ОК>Спасибо за просвещение но данный параграф только отвлекает от дискуссии.

Это я тебе пытался продемонстрировать, когда " well defined interface" работает, а когда нет. Ну да, бог с ним, проехали. Если уж простейшие аналогии не работают...

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

Кто тебе сказал, что мне от базы нужны какие-то там точки? БД должна надёжно сохранять и быстро выдавать. Какие ещё точки?

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

Зачем? Мне ещё только чёрных ящиков в моём собственном коде не хватало.

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

Знаешь чем теория отличается от практики? С точки зрения теории между теорией и практикой нет разницы, а с точки зрения практики есть.

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

Где?

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

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

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

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

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

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

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

Код на C# никуда не лезет, потому что лезть просто некуда. Есть только C# код и ничего больше.

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

MC>Когда я думаю о том, что в будущем я могу попасть на проект, где вся работа с БД опять будет на хранимых процедурах, у меня по рукам пробегают мурашки.

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

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

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

Скажите, а как решить поставленную задачу при наличии тех же требований, в случае если GetCustomerByID — это класс/компонент/метод и т.п. реализованный на C# с использованием LINQ? На мой взгляд варианта два. Но прежде всего нужно разобраться с существующей реализацией и понять насколько новые изменения затронут имеющийся C# код. На основании проведенного исследования необходимо принять решение — сделать изменения в классе/компоненте/методе и т.п и автоматом распространить их на остальной код, где так же может что-то поплыть, либо реализовать новый класс/компонент/метод на C# и LINQ. И с этой точки зрения хранимая процедура ведет себя аналогично, нужно понять влияние изменений на существующий код и выбрать правильное решение об изменении, либо создании новой процедуры.

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

MC>Я примерно 9 лет работал с хранимыми процедурами. Последние годы работаю с linq2db. Т.е. сравнить могу.
MC>У хранимых процедур на мой взгляд две основные проблемы — отладка и рефакторинг. И если с отладкой еще можно примириться, благо некоторые IDE предоставляют отладку хранимых процедур, то рефакторинг становится либо невозможным, либо превращается в кошмар и вылезающие в run-time баги.
MC>Хранимые процедуры, на мой взгляд, должны использовать только тогда, когда они совершенно необходимы, в каких-то конкретных частях проекта, но не как основной инсрумент работы с БД.

А вы можете перечислить пожелания или требования к функционалу рефакторинга БД? Как показывает практика, в большинстве случаев разработчикам достаточно кнопки с функциональностью схожей в C# проектах, которая вызывается через Refactoring -> Rename (F2).

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

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

А в случае нормализации\денормализации много кода на C# переписать придется? Маппинг таблиц на классы в linq2db достаточно гибок, чтобы изолировать от этих изменений?

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

O>Скажите, а как решить поставленную задачу при наличии тех же требований, в случае если GetCustomerByID — это класс/компонент/метод и т.п. реализованный на C# с использованием LINQ?

Всмысле переписать существующий код на LINQ?

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

A>А в случае нормализации\денормализации много кода на C# переписать придется? Маппинг таблиц на классы в linq2db достаточно гибок, чтобы изолировать от этих изменений?

Мы в текущем проекте с linq2db массируем и жонглируем таблицами и колонками как хотим. С ХП это было бы невозможно (точнее возможно, но потраченного времени и багов было бы на порядок+ больше). Правда стоит отметить, что у нас поверх модели данных есть еще объектная модель (более приближенная к бизнесу), и бизнес-логика работает в основном с этой объектной моделью. Это позволяет инкапсулировать изменения. Т.е. при рефакторинге БД мы чиним внутренности объектной модели (иногда это простейшее обновление маппинга), а остальной код, который работает с этой объектной моделью не меняется.

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

O>А вы можете перечислить пожелания или требования к функционалу рефакторинга БД? Как показывает практика, в большинстве случаев разработчикам достаточно кнопки с функциональностью схожей в C# проектах, которая вызывается через Refactoring -> Rename (F2).

Да вроде полный набор:

Переименование, изменение типа, добавление, удаление таблиц и колонок.
Перенос таблиц в другие схемы
Объединение или разделение таблиц.

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

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

O>>Скажите, а как решить поставленную задачу при наличии тех же требований, в случае если GetCustomerByID — это класс/компонент/метод и т.п. реализованный на C# с использованием LINQ?

IT>Всмысле переписать существующий код на LINQ?

Я хотел спросить, что нужно сделать если у вас есть GetCustomerByID реализованный на C# и LINQ, а перед вами стоит задача "вот здесь вот этот фактор надо бы ещё домножить на вот это число из вот этой таблицы"? Пытаюсь понять какие преимущества даст ваш подход перед процедурным в данном случае.

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

O>Я хотел спросить, что нужно сделать если у вас есть GetCustomerByID реализованный на C# и LINQ, а перед вами стоит задача "вот здесь вот этот фактор надо бы ещё домножить на вот это число из вот этой таблицы"?

В том то и дело, что у меня нет GetCustomerByID. Я не создаю микрометодов с бизнес логикой. Даже миниметодов не создаю. Если в двух местах часть бизнес логики потребует GetCustomerByID, то я в двух местах напишу

db.Customer.FirstOrDefault(c => c.CustomerID == id);

А когда мне в одном из мест понадобится внести изменение, то я даже не буду думать в каких там местах у меня похожий код. Я просто где надо напишу:

db.Customer.OrderBy(c => FirstName).FirstOrDefault(c => c.CustomerID == id);

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

O>Пытаюсь понять какие преимущества даст ваш подход перед процедурным в данном случае.

Не перед процедурным, а перед текстуальным представлением SQL. В моём распоряжении все средства, доступные C#: типизация, навигация, рефакторинги, приличный отладчик. Любое ломающее изменение в БД у меня сразу ломает код. Пока я с этим не разберусь, моё приложение не собирается. В случае с текстуальным SQL я могу сколь угодно много его менять и словить проблему только в рантайм в продакшине.

Поскипана куча букв не имеющих отношения к вопросу.

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

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

Где я такое сказал? Ты опять присваиваешь мне свои слова! Все что я сказал, это "на нижнем уровне стэка у тебя есть база, язык которой SQL."

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

IT>Код на C# никуда не лезет, потому что лезть просто некуда. Есть только C# код и ничего больше.

Да? А вот это что такое?

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);
                }
            }
        }
    }
}

У тебя не только Си Шарповский код дублирует структуру базы, но и полагается на внутренности самой базы!

З.Ы. На вопросы ты так и не ответил! Потому что не можешь ответить!

H>>О большинстве проектов, в которых хранимки декларировались как "единственные "точки входы" через которые ты можешь что-то получить от базы" у меня лично остались крайне неприятные воспоминания.

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

Да ты ведь даже не понял его ответа! Хрен горы согласился с тем, что linq2db нарушает инкапсуляцию базы, но тем не менее, по его мнению, если технология удобна, то почему бы не плюнуть на философию и тупо не использовать ее в проекте? Я, в принципе, согласен с таким утверждением, но лично мне, как purist-у, не просто такое (ORM фреймворки) принять.

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

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

Ну и сами ORM фреймворки тоже имеют проблемы помимо этой. Вот простейший пример: запрос пишется на другом языке — Си Шарп или Джава — и чтобы его проверить, нужно скомпилировать код и проранать его. Для сравнения, запросы на сиквеле можно сразу же проранать в менеджмент студии. Меньше телодвижений. Точно также и отладка. Надо получить созданный сиквел и проранать его в студии если что-то непонятно. Не забываем, что нижележащий инструмент все-таки разговаривает на сиквеле.

Вообще все эти ORM фреймворки один большой костыль, но что-то ломает меня продолжать отвечать здесь.

MC>>Когда я думаю о том, что в будущем я могу попасть на проект, где вся работа с БД опять будет на хранимых процедурах, у меня по рукам пробегают мурашки.

IT>Вот! Послушайте ещё одного умного человека!

Удобство не отменяет филосовских проблем с технологией! О чем я тебе уже который пост говорю.

O>>Пытаюсь понять какие преимущества даст ваш подход перед процедурным в данном случае.

IT>Не перед процедурным, а перед текстуальным представлением SQL. В моём распоряжении все средства, доступные C#: типизация, навигация, рефакторинги, приличный отладчик. Любое ломающее изменение в БД у меня сразу ломает код. Пока я с этим не разберусь, моё приложение не собирается. В случае с текстуальным SQL я могу сколь угодно много его менять и словить проблему только в рантайм в продакшине.

Ну а неправильные запросы как ты отлаживаешь? Свои и чужие. Речь сейчас о Си шарпе, если что.

MC>По поводу инкапсуляции. Во-первых, как уже упоминалось, всякие сортировки и пейджинги — это не implementation details, это бизнес-логика.

А бизнес логика это что ли не implementation details?

MC>Во-вторых, никто лично вам не мешает выделить DAL для повышения инкапсуляции, структуризации, повторного использования. На позапрошлом проекте я так и делал, использовал linq2db, но при этом по-старинке выделял DAL. Если вы хотите, чтобы одинаковые запросы выполнялись на разных клиентах — пожалуйста, можно сделать веб-сервис, который внутри будет использовать linq. Кстати, то "нарушение инкапсуляции" здесь очень сильно играет на руку в плане рефакторинга и find usages.

Как бы ты там не повышал инкапсуляцию в клиентском коде, инкапсуляция базы-то нарушена!

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

O>>А вы можете перечислить пожелания или требования к функционалу рефакторинга БД? Как показывает практика, в большинстве случаев разработчикам достаточно кнопки с функциональностью схожей в C# проектах, которая вызывается через Refactoring -> Rename (F2).

MC>Да вроде полный набор:

Я вас понял, спасибо. Не знаю с какой СУБД вы работаете, кроме того возможно вы уже в курсе, но в качестве примера упомяну о таком продукте как SSDT от Microsoft, который появился с 2012 версией SQL Server и начал свое распространение со студии 2010. Не могу сказать про остальные СУБД и инструменты, но в наши дни, думаю найдутся приложения, которые облегчают труд разработчика при работе с БД.

SSDT инструмент интегрированный в Visual Studio предоставляет возможности по проектированию и разработке баз данных для всех версий сервера начиная с 2005. Фактически это отдельный проект, который представляет собой эволюционное развитие старых VSDB проектов. Я не буду описывать существующие возможности, просто скажу несколько слов по требованиям, которые вы предъявили.

MC>Переименование

Все объекты БД можно переименовать Refactor -> Rename (F2), причем переименовывается не только сам объект, но и все ссылки на него в связанных объектах и скриптах.

MC>изменение типа,

Для изменения типа вам придется найти все ссылки на колонки и проверить их использование. Потому что варианты, например, с промежуточным использованием переменных или параметров ХП, автоматически не будут разрулены. Возможно, если поле часто меняется, то стоит рассмотреть подход с выделением отдельного пользовательского типа, который используется для колонки, объявлений, параметров ХП и прочее. В таком случае студия сама разрешит эту ситуацию. СтОит отметить, что инструмент не выполнит самостоятельно преобразование данных, например от int к datetime, это остается на совести разработчика.

MC>добавление, удаление таблиц и колонок.

Если вы удалили колонку, таблицу или другой объект, а в объектах БД осталась ссылка на них, то при компиляции проекта вы получите список ошибок с сообщением об отсутствующем объекте. Здесь необходимо руками выкосить все ссылки, но ждать рантайма для ловли ошибок не придется.

MC>Перенос таблиц в другие схемы

Выполняется через команду Refactor -> Move to Schema … (Ctrl + R, M) Причем смена схемы будет выполнена не только на самом объекте, но и на всех ссылках, которые встречаются в проекте.

MC>Объединение или разделение таблиц.

Готового функционала по разделению таблиц нет, а вот объединить таблицы можно переименовав одну из таблиц, и дополнив недостающими полями оставшуюся.

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

Приведенный мной пример, не отменяет конечно же возникшей здесь дискуссии, просто для СУБД MS SQL сервер существует инструмент, который помогает решать повседневные задачи, чего не было буквально несколько лет назад.