Сейчас с БД работать вообще не модно, если почитать рсдн Сейчас модны хитровыверты на функциональных языках, веб и мобильная разработка. Кто про БД заикнется значит замшелый старпер из мухосранска вылез.
Жизнь не обязана доставлять удовольствие. Достаточно отсутствия страданий.
Re: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, sushko, Вы писали:
S>Вопрос: а какой сейчас есть мейнстримовый путь работы с базами данных? Ну, например, из MSVisualC или из любого другого средства разработки "общего характера"?
Если есть возможность использовать .NET, то только LINQ и никаких древних какашек мамонта типа ODBC.
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Олег К., Вы писали:
ОК>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, был с радостью выброшен, и многослойная архитектура со всеми её анахронизмами окончательно ушла из моей жизни.
ОК>На всякий случай приведу код из твоего блога для ясности:
Это пример, демонстрирующий использование библиотеки, но ты сделал по нему вывод о моих архитектурных предпочтениях. Ну-ну.
ЗЫ. Предыдущий ответ почему отправился недописанным самопроизвольно.
Если нам не помогут, то мы тоже никого не пощадим.
Re[23]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Olaf, Вы писали:
O>Я хотел спросить, что нужно сделать если у вас есть GetCustomerByID реализованный на C# и LINQ, а перед вами стоит задача "вот здесь вот этот фактор надо бы ещё домножить на вот это число из вот этой таблицы"?
В том то и дело, что у меня нет GetCustomerByID. Я не создаю микрометодов с бизнес логикой. Даже миниметодов не создаю. Если в двух местах часть бизнес логики потребует GetCustomerByID, то я в двух местах напишу
Но на практике такие мелкие запросы обычно превращаются в часть запросов более крупного запроса, поэтому таких повторяющихся мест почти не бывает.
O>Пытаюсь понять какие преимущества даст ваш подход перед процедурным в данном случае.
Не перед процедурным, а перед текстуальным представлением SQL. В моём распоряжении все средства, доступные C#: типизация, навигация, рефакторинги, приличный отладчик. Любое ломающее изменение в БД у меня сразу ломает код. Пока я с этим не разберусь, моё приложение не собирается. В случае с текстуальным SQL я могу сколь угодно много его менять и словить проблему только в рантайм в продакшине.
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Олег К., Вы писали:
ОК>Ну надо же. Хранимые процедуры позволяют тебе написать запрос один раз а затем использовать его в разных проектах. Вместо этого ты предлагаешь плодить запросы.
Именно хранимки именно для переиспользования различными несвязанными между собой приложениями — это ужасно. Потому что никакой поддержки рефакторинка и поиска использований. Может подойти только для реализации очень сложного и важного кода, который либо никогда не меняется, либо за которым очень строго следят кто какую процедуру использует.
ОК>Я тебе приведу другой пример, встречающийся часто на практике. Какой-нибудь фронт энд показывающий кучу цифр а также репорты, предоставляющие те же самые данные. Часто бывает, что цифры они показывают разные. Начинаешь разбираться, а там один и тот же запрос в двух местах. Со временем кто-то изменил логику в одном месте а про другое забыл.
Бывает и наоборот. У тебя есть хранимка и твое приложение ее использует. И вдруг при определенной версии приложения потребовалось немного изменить правила выборки в этой хранимке — сигнатура та же, логика другая. Ну поменял, все хорошо.
А через Х времени раз — и выяснилось, что этой же хранимкой иногда пользовалось какое-то совсем другое приложение (чтобы не плодить запросы), про которое все забыли, и там логика никак не должна была измениться, а теперь там все неправильно.
На мой взгляд это сложнее отловить, чем понять, почему отчет выдает неправильные данные если ведь его запрос — вот, перед глазами, а не обращение к хранимке с вводящим в заблуждением названием а-ля "spActualBuilderForThisReport" — все процедуры код дергает правильно, а на выходе фигня.
В результате, дублируемые запросы — это дополнительная работа и возможность ошибок вида "а еще вот про этого клиента забыли, он работает как и раньше, без изменений. Давайте поправим когда сможем". Неприятно, но обычно не смертельно. А активное переиспользование хранимок становится похожим на хождение по минному полю, когда не знаешь к чему приведет исправление любой из них, и в каком месте вдруг вылезет проблема. Причем ты может быть нашел явный баг, или неточность в спецификации, но возможно, что для одного из клиентов данной хранимки — это совсем не баг, а даже фича, и исправление приведет к ошибкам в приложении про которое ты даже не знаешь.
Re[18]: А как сейчас модно работать с БД из-под Windows?
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);
}
}
}
}
}
Re[16]: А как сейчас модно работать с БД из-под Windows?
IT>> Есть вещи, которые, например, в linq2db пока не реализованы. Но это не вопрос невозможности, это вопрос целесообразности.
W>Вот и я о том же, о целесообразности.
Я бы вообще поставил вопрос целесообразности linq2db ибо она нарушает software engineering principles. Кто-то об этом не задумывается (включая автора), а мне, как purist-у, сложно это принять.
Re[26]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Олег К., Вы писали: IT>>На философию мне положить большой болт. Это самое последнее о чём нужно думать. Есть более важные вещи, такие как поддержка кода и организация рабочего процесса ОК>Ну так ты начни писать еще в стиле Си — откажись от функций членов и сделай все переменные члены публичными. Тебе ж положить на философию большой болт.
Подозреваю, если для решения некоторой конкретной задачи программирование в процедурном стиле (в стиле Си, как ты пишешь) без инкапсуляции, приватных методов и свойств позволит создать более компактный, выразительный, легко читаемый, тестируемый и поддерживаемый код, то Игорь без колебаний махнет рукой на все фенечки ООП. Для HelloWord или вычисления корней квадратного уравнения ты же станешь приватные методы писать правда (я утрирую конечно)?
Другой вопрос — даст ли переход на Си-стиль какой-нибудь профит?
А вот от отказа от DAL Игорь, очевидно, профит получает.
Вообще, всякие паттерны, ООП, вирутальности, инкапсуляции, слоистую структуру, ORM-ы, сервисы и пр, и пр, и пр. придумали для того, чтобы сделать код проще для написания, понимания и рефакторинга. Иными словами все выше перечисленное — не есть самоцель, а лишь инструменты. Цель — достижение простоты и выразительности. Вернее снижение сложности в одном аспекте за счет неизбежного повышения сложности с другом аспекте (у Игоря на этот счет есть замечательная, кстати, вполне философская статья
).
Если инструмент подходит для достижения цели, его используют, если не подходит — его не используют.
Когда-то, тот же IT, если не ошибаюсь, писал (ссылку уже не найду), что иметь слой DAL в программе — это так же считается хорошим тоном как чистить зубы по утрам и вечерам. Но если зубов нет, то и чистить, в общем-то, ничего не надо. Иными словами, задача слоя DAL в одном месте локализовать функционал преобразования нетепизированных объектов БД в строго типизированные объекты языка программирования (C# например) и наоборот. Если проблемы с этим преобразованием нет (а LINQ эту проблему снимает), то проблема, которую призван решить DAL, исчезает. Соответственно, становится не нужным и сам DAL.
Твой же пуристический подход предполагает следование догмам независимо от того нужны ли они и продуктивны ли.
Красота — наивысшая степень целесообразности. (c) И. Ефремов
Здравствуйте, s_aa, Вы писали:
_>Сейчас с БД работать вообще не модно, если почитать рсдн Сейчас модны хитровыверты на функциональных языках, веб и мобильная разработка. Кто про БД заикнется значит замшелый старпер из мухосранска вылез.
(Пожимая плечами) Ну у тех, кому нужно управлять данными в базах данных, дофига денег (я бы сказал — 90% денег, которые IT может получить, находятся у них), так что у замшелых старперов (к которым, безусловно, отношусь и я) таки есть шанс
Здравствуйте, Alex.Che, Вы писали:
AC>носкул нафиг не упёрся, если есть полноценная RDBMS
Это зависит от особенностей системы, внезапно. Тот же Hangfire более эффективно использует Redis кэш, нежели SqlServer. Разумеется,
я не предлагаю все хранить в NoSQL хранилище, но если можно его эффективно использовать для увеличения быстродействия/
уменьшения времени отклика системы, то почему нет? Главное же, чтобы пользователь был счастлив, а не вероисповедание разработчиков
Re[5]: А как сейчас модно работать с БД из-под Windows?
S>Вопрос: а какой сейчас есть мейнстримовый путь работы с базами данных? Ну, например, из MSVisualC или из любого другого средства разработки "общего характера"?
Все БД уже давно крутятся на разных юниксах, а под виндой бд мало кому нужны
Re[13]: А как сейчас модно работать с БД из-под Windows?
У меня другое мнение.
ОК>>На счет последнего предложения. Представь что у тебя два проекта. Один на .НЕТ-е, другой на Джаве. И нужен этим приложениям один и тот же запрос. Будешь плодить запросы на разных технологиях?
IT>Конечно, буду.
Ну надо же. Хранимые процедуры позволяют тебе написать запрос один раз а затем использовать его в разных проектах. Вместо этого ты предлагаешь плодить запросы.
IT>Наличие двух приложений не означает, что они делают одно и тоже. А если это и так, то одно из них можно смело выкинуть.
Речь об одном и том же запросе а не об одном и том же приложении.
IT>Если же приложения делают разные вещи, то им нужны и разные запросы к базе данных и нет абсолютно никакого смысла пытаться городить огород из универсальных компонентов.
То есть ты хочешь сказать, что в разных приложениях не может быть одного и того же запроса?
IT>Всё это проходили уже тысячу раз. Даже на этом сайте есть три клиента, которые ходят в базу данных: web, janus, nntp. У всех не просто разные запросы, у всех даже структура и принципы выборки данных разные. Более того, т.к. сайт существует уже 15 лет, то здесь хоть и нет джавы, но наслоений технологий хватает. В том числе часть запросов написана на SQL, часть на LINQ. И никаких особых затруднений это не вызывает.
Этот сайт — несложный и интуитивно понятный проект. Юзер это юзер, пост это пост и т.д. Более того, у меня сомнения, что этот сайт меняет, улучшает, добавляет функциональность куча программистов работающих над ним фулл-тайм. Поэтому это не удачный пример но речь не об этом.
Ты привел один частный случай в то время как я говорил об общем случае. Пример ниже.
ОК>>А если три проекта или даже больше? Напомню, что в энерпрайзе с БД могут работать много разных приложений.
IT>Да хоть сколько. Я вообще не очень понимаю этого вопроса. Как наличие нескольких приложений могут повлиять на дизайн одного из них? Ну вот есть у нас на работе внешная Oracle БД, к которой нам дали доступ и из которой мы периодически черпаем данные. Я даже понятия не имею какие там есть ещё клиенты и на чём они написаны. Тем более, ни их число, ни их технологии на мой дизайн не могут повлиять никак.
А ты мысли не одним приложением а целой системой, группой приложений или процесов делающих что-то для бизнеса.
Я тебе приведу другой пример, встречающийся часто на практике. Какой-нибудь фронт энд показывающий кучу цифр а также репорты, предоставляющие те же самые данные. Часто бывает, что цифры они показывают разные. Начинаешь разбираться, а там один и тот же запрос в двух местах. Со временем кто-то изменил логику в одном месте а про другое забыл.
А теперь представь, что разные группы работают над этими проектами. Начинаются выяснения какой из этих запросов правильный, как должно считаться и еще куча всего. Поэтому я и говорю, что запросы должны находиться в самом низу стэка, т.е. в базе.
IT>В общем, в чём суть претензий не понятно
Ну так об этом и речь. Ты не понимаешь software engineering принципов ради которых создали хранимые процедуры и тупо восхваляешь LINQ, хотя он философски неверен даже в контексте одного приложения.
Re[18]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, wildwind, Вы писали:
IT>> Сервисы в БД — это мазохизм. Ни отладчика, ни средств навигации по коду, ни средств рефакторинга. Некоторые базы типа Sybase вообще теряют контекст, если вызвать из одной процедуры другую. Языковые средства стары как какашки мамонта. Сам язык нетипизированный, пиши что хочешь, а потом лови в рантайме, если повезёт создать удачный сценарий. Можно легко грохнуть или переименовать таблицу и никто этого не заметит до падения системы в продакшине.
W>Опять-таки, делай оговорку про личный опыт.
Это само собой. Есть только одно маленькое дополнение. Мой опыт включает как интенсивное использование сохранённых процедур и прямого SQL, так и не менее интенсивное использование LINQ. Я могу вполне объективно сравнивать.
Если нам не помогут, то мы тоже никого не пощадим.
Re[28]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Олег К., Вы писали:
S>>Для HelloWord или вычисления корней квадратного уравнения ты же станешь приватные методы писать правда (я утрирую конечно)? ОК>Не стану.
Т.е. ты согласен с тем, что инструмент надо применять там, где его применение дает профит? А там, где не дает, там его применять не надо?
S>>А вот от отказа от DAL Игорь, очевидно, профит получает. ОК>При чем тут ДАЛ? Ты вообще понял о чем речь? База открыта, а ты мне тут про ДАЛ. DAL — это инструмент преобразования нетипизированных объектов в типизированные и обратно (это просто пример того инструмента, от которого IT отказался и говорит об этом прямо).
Аналогично, слой представлений (View) и хранимых процедур — это инструмент обеспечения некоторой абстракции от структуры таблиц.
Насколько я тебя понял, ты хочешь скрыть от кода, написанного на C# (или C++, или Java, или др.аналогичном языке) структуру БД.
Вопрос в том, нельзя ли от второго инструмента отказаться так же как от первого?
Ты хочешь (поправь, если я ошибаюсь) сделать так, чтобы:
1. БД сама "отвечала" за целостность хранящихся в ней данных и клиентский (по отношению СУБД) код не мог нарушить целостность данных
2. Клиентский (по отношению к СУБД) код взаимодействовал с более высоким уровнем абстракции бизнес-сущностей (например JOIN нескольких таблиц, не заботясь о том, как эта бизнес-сущность "размазана" по таблицам внутри БД).
Применение хранимых процедур и представлений (View) все это может обеспечить. Причем не только теоретически, но и практически.
А зачем надо абстрагироваться от структуры таблиц? Что нам даст слой хранимок, разделяющий слои таблиц БД и клиентский (с точки зрения СУБД) код? Возможность внести изменения в структуру таблиц так, что клиентский код этого не заметит, достаточно будет только слой хранимых процедур поправить? С этим я согласен. В теории.
Но во-первых, часто ли изменение структуры БД выполняется независимо от бизнес-логики (которая на C# написана)? Мне обычно после изменения структуры БД приходится изменения пробрасывать до диалогов, которые видит пользователь, т.е. через все слои до самого верха. И чем больше таких слоев, тем больше изменений.
А во-вторых, даже если абстракция нужна, почему этот слой абстракции должен быть выполнен именно в хранимых процедурах SQL? Почему он не может быть реализован на C#/Java/C++ ? При изменении структуры таблицы (добавление, удаление, переименование, смена типа столбца) где будет проще поправить код работы с таблицей: в нескольких хранимых процедурах (надо вспомнить в каких из нескольких тысяч) или в коде на C# ? При этом надо иметь в виду, что проверифицировать модель данных в C# (чтобы она соответствовала структуре таблиц в БД) можно автоматизированно, и затем при компиляции программы компилятор сам проверит имена столбцов и соответствие типов. А вот соответствие кода хранимых процедур структуре таблицы для процедур, сохраненных до изменения структуры, проверить получится только при обращении к этим хранимкам (в тестах?)
ИМХО на C# проблем огребается меньше... Кроме того, C#/Java/C++ позволяют писать более компактный (и при этом не в ущерб читаемости) код, чем тот же T-SQL (особенности синтаксиса).
Где я не прав?
ОК>Ну и коли ты решил выступить его адвокатом, тогда объясни почему он выборочно так поступает? Дальше, объясни почему он впадает в истерику на справедливое, в принципе, замечание?
Я ничьим адвокатом не выступаю. Просто я довольно давно слежу за "творчеством" IT на этом сайте. И не могу не признать, что он действительно говорит (и, кстати, делает) правильные вещи (хотя мои шаблоны он иногда рвет, да). Я понимаю что говорит тебе Игорь. (или думаю, что понимаю)
Твою основную мысль не очень понимаю.
Твой с IT диалог превратился в холивар. В диалог слепого с глухим. Такое читать весело, но бесполезно.
IT в нескольких постах повторяет одно и то же: практическая целесообразность и эффективность важнее теории.
До сих пор твои возражения звучали как: "неправда, теория важнее". Извини, если что, но со стороны это звучит именно так.
Как понимать этот твой ответ: S>>Твой же пуристический подход предполагает следование догмам независимо от того нужны ли они и продуктивны ли. ОК>Это не так. Даже на сиквеле можно писать понятный и поддерживаемый код. Другое дело, что большинство не умеет. Соответственно у большинства будет код на Си шарпе не лучше кода на сиквеле.
?
Ты уверен, что на сегодняшнем уровне развития средств разработки создание и поддержка слоя хранимых процедур, обеспечивающего полную абстракцию от таблиц БД, может быть не менее эффективна, чем применение Linq на "голых" таблицах?
Или же ты допускаешь, что слой абстракции из хранимых процедур более проблематичен, но он должен быть потому что так говорит теория?
Красота — наивысшая степень целесообразности. (c) И. Ефремов
Здравствуйте, 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 сервер существует инструмент, который помогает решать повседневные задачи, чего не было буквально несколько лет назад.
Re[21]: А как сейчас модно работать с БД из-под Windows?
On 14.09.2015 09:53, "Олег К." wrote:
> Я соглашусь с тобой, что хранимки не без проблем, но это *философски* > самое правильное решение, нравится оно тебе или нет.
"Суха, мой друг, теория везде, А древо жизни пышно зеленеет." (с)
О большинстве проектов, в которых хранимки декларировались как
"единственные "точки входы" через которые ты можешь что-то получить от
базы" у меня лично остались крайне неприятные воспоминания. Попытки
выразить бизнес-логику убогими средствами PL/SQL (T-SQL, etc.) которые я видел лично — калечны и непродуктивны, создают
значительные проблемы в развитии проекта, вообщем создают больше
практических проблем чем наносят философской пользы.
Возможно, впрочем, что где-то и существуют хрустальные дворцы на холмах.
--
WBR,
Serge.
Posted via RSDN NNTP Server 2.1 beta
Re: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, sushko, Вы писали:
S>Вопрос: а какой сейчас есть мейнстримовый путь работы с базами данных? Ну, например, из MSVisualC или из любого другого средства разработки "общего характера"?
Ты наверное не поверишь -- СНОВА ODBC!
Re[22]: А как сейчас модно работать с БД из-под Windows?
Кому что. Сиквел убог, и я не могу с тобой не согласиться. Нравится технология — используй ради бога, что, однако, не отменяет философских проблем с ней о которых большинство даже и не задумывается.
Ну и сами ORM фреймворки тоже имеют проблемы помимо этой. Вот простейший пример: запрос пишется на другом языке — Си Шарп или Джава — и чтобы его проверить, нужно скомпилировать код и проранать его. Для сравнения, запросы на сиквеле можно сразу же проранать в менеджмент студии. Меньше телодвижений. Точно также и отладка. Надо получить созданный сиквел и проранать его в студии если что-то непонятно. Не забываем, что нижележащий инструмент все-таки разговаривает на сиквеле.
Вообще все эти ORM фреймворки один большой костыль, но что-то ломает меня продолжать отвечать здесь.
Re[12]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Олег К., Вы писали:
ОК>А ты разве не это же самое делаешь?
Нет.
ОК>На счет последнего предложения. Представь что у тебя два проекта. Один на .НЕТ-е, другой на Джаве. И нужен этим приложениям один и тот же запрос. Будешь плодить запросы на разных технологиях?
Конечно, буду. Наличие двух приложений не означает, что они делают одно и тоже. А если это и так, то одно из них можно смело выкинуть. Если же приложения делают разные вещи, то им нужны и разные запросы к базе данных и нет абсолютно никакого смысла пытаться городить огород из универсальных компонентов. Всё это проходили уже тысячу раз. Даже на этом сайте есть три клиента, которые ходят в базу данных: web, janus, nntp. У всех не просто разные запросы, у всех даже структура и принципы выборки данных разные. Более того, т.к. сайт существует уже 15 лет, то здесь хоть и нет джавы, но наслоений технологий хватает. В том числе часть запросов написана на SQL, часть на LINQ. И никаких особых затруднений это не вызывает.
ОК>А если три проекта или даже больше? Напомню, что в энерпрайзе с БД могут работать много разных приложений.
Да хоть сколько. Я вообще не очень понимаю этого вопроса. Как наличие нескольких приложений могут повлиять на дизайн одного из них? Ну вот есть у нас на работе внешная Oracle БД, к которой нам дали доступ и из которой мы периодически черпаем данные. Я даже понятия не имею какие там есть ещё клиенты и на чём они написаны. Тем более, ни их число, ни их технологии на мой дизайн не могут повлиять никак.
В общем, в чём суть претензий не понятно
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Олег К., Вы писали:
ОК>У меня другое мнение.
у тебя неверное другое мнение.
ОК>Ну надо же. Хранимые процедуры позволяют тебе написать запрос один раз а затем использовать его в разных проектах. Вместо этого ты предлагаешь плодить запросы.
Я же только что объяснял, что если у вас один запрос на несколько проектов, то у вас что-то не так с несколькими проектами.
IT>>Наличие двух приложений не означает, что они делают одно и тоже. А если это и так, то одно из них можно смело выкинуть. ОК>Речь об одном и том же запросе а не об одном и том же приложении.
Т.е у тебя несколько приложений делают одно и тоже? Может быть имеет смысл задуматься о?
IT>>Если же приложения делают разные вещи, то им нужны и разные запросы к базе данных и нет абсолютно никакого смысла пытаться городить огород из универсальных компонентов. ОК>То есть ты хочешь сказать, что в разных приложениях не может быть одного и того же запроса?
Вполне может быть. Только здесь есть два момента. Либо мы говорим о повтоно используемых компонентах, либо мы плавно переходим к повторно используемому коду в бизнес логике.
По первому всё просто. Это должно быть реализовано ввиде повторно используемого компонента, где запрос, та-да, будет реализован один раз.
Второе — один из признаков незрелости архитектора приложения. Повторно используемая бизнелогика — это мифологема типа древние укры выкопали Чёрное море. В теории да, но на практике очень геморно. Одно из свойств бизнес логики её постоянная изменяемость. Если завтра изменятся требования к одной части приложения, исользующей общий запрос в части общего запроса, то встанет дилема — либо написать новый запрос, либо обратиться к проматери всех парадигм — флажговому программированию, т.е. трансформировать нормальный код в говно код.
IT>>Всё это проходили уже тысячу раз. Даже на этом сайте есть три клиента, которые ходят в базу данных: web, janus, nntp. У всех не просто разные запросы, у всех даже структура и принципы выборки данных разные. Более того, т.к. сайт существует уже 15 лет, то здесь хоть и нет джавы, но наслоений технологий хватает. В том числе часть запросов написана на SQL, часть на LINQ. И никаких особых затруднений это не вызывает.
ОК>Этот сайт — несложный и интуитивно понятный проект. Юзер это юзер, пост это пост и т.д. Более того, у меня сомнения, что этот сайт меняет, улучшает, добавляет функциональность куча программистов работающих над ним фулл-тайм. Поэтому это не удачный пример но речь не об этом.
Нормальный пример. Пафос про программирование ядерных реакторов здесь не уместен. Мне доводилось писать код для МинЮста, ГазПрома, РКА и нескольких ведущих американских банков. Архитектура всего этого при правильном подходе не принципиально отличается от этого сайта. Ты правда хочешь об этом поговорить?
ОК>Ты привел один частный случай в то время как я говорил об общем случае. Пример ниже.
Общих случаев в программировании не бывает. Точнее общий случай в программировании реализуется один единственный раз. В строительстве нельзя построить два одинаковых здания за один раз. В программировании можно.
IT>>Да хоть сколько. Я вообще не очень понимаю этого вопроса. Как наличие нескольких приложений могут повлиять на дизайн одного из них? Ну вот есть у нас на работе внешная Oracle БД, к которой нам дали доступ и из которой мы периодически черпаем данные. Я даже понятия не имею какие там есть ещё клиенты и на чём они написаны. Тем более, ни их число, ни их технологии на мой дизайн не могут повлиять никак.
ОК>А ты мысли не одним приложением а целой системой, группой приложений или процесов делающих что-то для бизнеса.
А ты сам хоть раз это пробовал? Или пока только теоретически?
ОК>Я тебе приведу другой пример, встречающийся часто на практике. Какой-нибудь фронт энд показывающий кучу цифр а также репорты, предоставляющие те же самые данные. Часто бывает, что цифры они показывают разные. Начинаешь разбираться, а там один и тот же запрос в двух местах. Со временем кто-то изменил логику в одном месте а про другое забыл.
Ещё раз, такие вещи нужно оформлять в виде повторно используемых компонентов и сервисов, а не доводить дело до базы данных и SQL.
ОК>А теперь представь, что разные группы работают над этими проектами. Начинаются выяснения какой из этих запросов правильный, как должно считаться и еще куча всего. Поэтому я и говорю, что запросы должны находиться в самом низу стэка, т.е. в базе.
Бизнес логика в базе — это анахронизм и/или вандализм. Тем более, что мне как программисту никто не запретит проигнорировать эту логику и написать свою. А база данных должна хранить и выдавать. Никаких других бизнес функций у неё быть не должно.
ОК>Ну так об этом и речь. Ты не понимаешь software engineering принципов ради которых создали хранимые процедуры и тупо восхваляешь LINQ, хотя он философски неверен даже в контексте одного приложения.
Блин, чувак, ну не стоило скатываться на персоналии. До сих пор ты производил впечатление вменяемого собеседника и вдруг нате вам — я Д'Артаньян, а вы все немытое быдло
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, wildwind, Вы писали:
W>Но все же не будем забывать, что LINQ на сегодняшний день реализует лишь подмножество SQL и его диалектов. Поэтому о "тотальном отсутствии" в серьезных проектах говорить не приходится. И, я полагаю, в будущем это так и останется. Кесарю — кесарево.
Я уже упоминал, что на сегодняшний день только одна вещь, не реализуемая на LINQ — иерархические CTE. И это всё! Всё остальное делается на LINQ и сопутствующих средствах влёт. Есть вещи, которые, например, в linq2db пока не реализованы. Но это не вопрос невозможности, это вопрос целесообразности. Понадобились в том же Oracle xml-таблицы — получите xml-таблицы. Понадобились в DB2 хинты, уровня запроса — получите хинты. Сделать можно всё. Даже тот же иерархический CTE не сделан только лишь потому, что пока не придумали как его выразить на C#.
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, sushko, Вы писали:
S>Hi, All!
S>Когда-то давно, во времена моей профессиональной юности для того, чтобы работать с базами данных определенного формата, нужно было выбирать определенную среду разработки, напр. DBF -> DBase. Потом появился ODBC, позволявший работать с любыми (условно говоря) базами данных из любой (условно говоря) среды разработки. Потом, кажется, был OLEDB, но к тому времени я с приложений "клиент->база данных" давно слез и это прошло мимо меня. Потом, наверное, еще что-нибудь могло быть...
S>Вопрос: а какой сейчас есть мейнстримовый путь работы с базами данных? Ну, например, из MSVisualC или из любого другого средства разработки "общего характера"?
1. ODBC. Там после него конечно куча технологий друг друга сменила, но каждая с какими-нибудь проблемами. В итоге odbc сейчас самый удачный, плюс сам майкрософт снова вспомнил про него, чуток обновил, добавил новых фишек и показывает на его как "передний край разработки".
2. Нативный дрова. oci, sqlncli, libpq, libmysqlclient и т.д., у каждой СУБД свой, со своим API (хотя функциональное сходство очень велико).
Re[4]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Alex.Che, Вы писали:
>> Да хоть на mainframe. Главное — где клиент. AC>на вэбе
Клиент базы данных не вебе? Это что-то новое в дизайне приложений. Особенно в части защиты доступа к данным. Даже SQL injection не нужен. Просто бери и грохай пользуйся.
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Cornetov, Вы писали:
C>Если одни разрабатывают серверную часть, другие клиентскую, третьи web решение, четвертые делают анализ данных через Excel, то даже мысли переходить назад к двухзвенке не появится.
А мужики то и не знают
Проблема двухзвенки в энтерпрайзе ровно одна — при большом количестве клиентов к серверу БД может быть открыто слишком много соединений, которые не являются для сервера БД бесплатным ресурсом. Самому же коду без разницы где работать — на сервере приложений или на машине клиента.
C>OData для такой архитектуры. WCF тоже, но сегодня явно уступает по возможностям.
Я не против этой философемы. Для этого они подходят. Не самым лучшим образом, но если регулярно принимать обезболивающее, то подходят. Чистое решение, снимающее вообще все проблемы присущие OData — это LINQ over WCF, реализованный в BLToolkit и linq2db.
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, IT, Вы писали:
IT>Проблема двухзвенки в энтерпрайзе ровно одна — при большом количестве клиентов к серверу БД может быть открыто слишком много соединений, которые не являются для сервера БД бесплатным ресурсом.
Вот именно, я изначально писал только про глобальное решение.
IT>Самому же коду без разницы где работать — на сервере приложений или на машине клиента.
Не нужно глобальное решение -- флаг в руки. Но баги выгребать будет сложенее.
C>>OData для такой архитектуры. WCF тоже, но сегодня явно уступает по возможностям.
IT>Я не против этой философемы. Для этого они подходят. Не самым лучшим образом, но если регулярно принимать обезболивающее, то подходят. Чистое решение, снимающее вообще все проблемы присущие OData — это LINQ over WCF, реализованный в BLToolkit и linq2db.
Ага! Зоопарк решений исключительно для .NET.
Re[17]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Олег К., Вы писали:
ОК>>>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# код и ничего больше.
Если нам не помогут, то мы тоже никого не пощадим.
Re[24]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Олег К., Вы писали:
IT>>Вот! Послушайте умного человека! ОК>Да ты ведь даже не понял его ответа!
Я с тебя ржу.
ОК>Хрен горы согласился с тем, что linq2db нарушает инкапсуляцию базы, но тем не менее, по его мнению, если технология удобна, то почему бы не плюнуть на философию и тупо не использовать ее в проекте? Я, в принципе, согласен с таким утверждением, но лично мне, как purist-у, не просто такое (ORM фреймворки) принять.
Я тебе тут уже целый пост про твою философию написал, но ты так ничего и не понял, пурист ты наш. Объясняю ещё раз. На философию мне положить большой болт. Это самое последнее о чём нужно думать. Есть более важные вещи, такие как поддержка кода и организация рабочего процесса. Тряпочка для протирки монитора важнее, чем вся твоя философия. И заканчивай уже на это напирать. На меня это действует с совершенно обратным знаком.
ЗЫ. Извини, но на патерны и прочий булшин у меня тоже передозировка. На одном из моих проектво был один дебил, который ходил с табличкой design pattern police. Своей философией и паттернами задолбал абсолютно всех. Там где он не мог применить никакого паттерна, он применял визитор паттерн. В конце концов, чувак этот в результате за неуспеваемость был разжалован из архитекторов в девелоперы. С тех пор у меня устойчивая аллергия на подобных филосовствующих придурков.
Если нам не помогут, то мы тоже никого не пощадим.
Re[24]: А как сейчас модно работать с БД из-под Windows?
Это провайдер использовался одно время в BLToolkit, но не прижился. Всё современные БД уже имеют вполне зрелые нативные .net провайдеры, поэтому в ODBC необходимость отпадает. К тому же, ODBC нужно дополнительнос ставить, а для большинства провайдеров этого не нужно.
AG>Так — в чём же проблема? В религии?
Ну вот, опять началось У меня сразу вопрос, у тебя есть хотя бы общее представление о LINQ?
AG>Может просто вериться, что раз LINQ появился позже, то он лучше
Понятно. На предыдущий вопрос можно не отвечать.
LINQ в принципе нельзя сравнивать с вещами типа ODBC. LINQ может работать поверх ODBC, ADO.NET, XML или просто объектов. linq2db, linq2sql, EF и прочие — это LINQ провайдеры для баз данных. Каждый со своими достоинствами и недостатками. Например, философия (где там Олег К.?) linq2db — это типизированный SQL интегрированный в C#. Филисофия EF (от которой постепенно отходят) — это жирный ORM, всемогутор, симулятор персистентности объектной модели приложения и поставщик прочих entity services. linq2sql — удачная проверка концепции, загубленная теми, кому эта технология в дальнейшем была отдана для поддержки и продвижения.
Если нам не помогут, то мы тоже никого не пощадим.
Re[25]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Олег К., Вы писали:
ОК>Очередной костыль. Родной язык базы — сиквел. Вместо этого писать те же самые запросы на Си шарпе лишь с одной целью — чтобы иметь возможность перенести их в Си шарповский код. Запросы те же, синтаксис только другой. Тебе не кажется это уродливым?
База — это хранилище данных. То есть место на диске или в оперативной памяти. Таким образом, родной язык для базы — это команды перемещения головки жёсткого диска, чтение секторов и т. п. Если вместо hdd оказывается ssd, внезапно, меняется язык для доступа к данным. Если база расположена in memory — то доступ к данным идёт на "языке" адресов ram. Хотел философию? Получай!
Современный разработчик оперирует объектами-сущностями. Эти объекты можно объединять в различные коллекции. Эти одиночные объекты и коллекции можно одной командой привязать к гую, послать по сети, сохранить/прочитать в/из файл(а). По твоей философии каждый раз нужно использовать собственный язык, "родной" для данного типа носителя, сети, графической библиотеки и т. п. Никто сейчас так не делает! Такова современная философия!
Если имеется у меня тип Person, то я хочу просто работать к коллекцией Persons, не важно, откуда она берётся и куда сохраняется. Если данные хранятся в xml-файле, то я прочитаю их двумя строками кода с помощью xml-сериализатора. Ты, вероятно, будешь считать этот файл побайтово, преобразоывать байты в нужную кодировку, парсить xml вручную, находить нужные элементы и атрибуты, записывать их в свойства класса. Мрак... Конечно, ты сразу вычленишь этот код чтения-парсинга в отдельные удобные классы/методы, назовёшь его DAL. Далее, прикладной программист будет использовать этот DAL (аналогично хранимкам в СУБД). То есть взаимодействия с "родным" языком хранилища у прикладника не будет!
В философии IT и меня точно также нет взаимодействия с сырыми байтами, прочитанными из файла и сырым sql СУБД. Вместо них используется ранее написанный кем-то DAL. Например, linq2db.
Я думаю ты согласишься, что не обязательно каждому разработчику напрямую взаимодействовать с БД? Кто-то пишет слой доступа, а кто-то им пользуется. Так вот linq2sql, EF, linq2db — это и есть заранее написанные кем-то функции работы с БД.
Очевидно, у тебя синдром NIH. Если ты сам написал хранимки — это хорошо. Если код доступа к БД сгенерирован кодом, написанным кем-то другим — это почему-то плохо.
Когда-то давно, во времена моей профессиональной юности для того, чтобы работать с базами данных определенного формата, нужно было выбирать определенную среду разработки, напр. DBF -> DBase. Потом появился ODBC, позволявший работать с любыми (условно говоря) базами данных из любой (условно говоря) среды разработки. Потом, кажется, был OLEDB, но к тому времени я с приложений "клиент->база данных" давно слез и это прошло мимо меня. Потом, наверное, еще что-нибудь могло быть...
Вопрос: а какой сейчас есть мейнстримовый путь работы с базами данных? Ну, например, из MSVisualC или из любого другого средства разработки "общего характера"?
Здравствуйте, sushko, Вы писали:
S>Вопрос: а какой сейчас есть мейнстримовый путь работы с базами данных?
Имхо, сейчас моден гибридный способ работы с БД. Основой является какая-нибудь ORM. Массовые операции вставки/удаления делаются в обход этой ORM, посредством bulk-операций. Если какие-то запросы в ORM неэффективны, их пишут сырым SQL.
Ну и самих БД сейчас модно иметь несколько: реляционная и NoSQL.
Re: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, sushko, Вы писали:
s> Вопрос: а какой сейчас есть мейнстримовый путь работы с базами данных? Ну, например, из MSVisualC или из любого другого средства разработки "общего характера"?
Нужно плясать не от средства разработки, а от базы. Открываешь доку, смотришь, какие есть интерфейсы и библиотеки для выбранного языка. Идеальный вариант получается, если СУБД и средство разработки от одного вендора.
Если же нужна кросс-платформенность или (не дай бог!) кросс-СУБД, то все гораздо сложнее. Как уже отметили, ODBC как был, так и до сих пор остается общим знаменателем. Были попытки родить новые: XML API, REST API, LINQ. Но, как говорится, пока не взлетело.
Ну и у NoSQL баз свой зоопарк, общих стандартов там пока нет.
Hardware eventually fails. Software eventually works. ::: avalon/1.0.442
Re[2]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, MasterZiv, Вы писали:
S>>Вопрос: а какой сейчас есть мейнстримовый путь работы с базами данных? Ну, например, из MSVisualC или из любого другого средства разработки "общего характера"?
MZ>Ты наверное не поверишь -- СНОВА ODBC!
Я рад, если честно. Зоопарк стандартов раздражал ужасно
Здравствуйте, IT, Вы писали:
IT>Вы уверены, что правильно понимаете значение слова "ретроград"? Может вы имели ввиду петроград или виноград?
Может он подумал, что ты имеешь в виду именно linq2sql.
Здравствуйте, sushko, Вы писали:
S>Вопрос: а какой сейчас есть мейнстримовый путь работы с базами данных? Ну, например, из MSVisualC или из любого другого средства разработки "общего характера"?
Мейнстрим для глобальных баз данных это создание БД на OData сервере. Клиент при этом может любым. Для виндовс приложений предпочтителен WPF, для веб angular и что попроще для создания т.н. single page web application.
Re[2]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Cornetov, Вы писали:
C>Мейнстрим для глобальных баз данных это создание БД на OData сервере.
Точнее мог бы быть мэйнстримом. Но когда кастрировали LINQ, чтобы сделать OData'у, то секанули не очень удачно и вместе с яцами отсекли всё, что висело ниже них. Т.е. ещё и ноги и кисти рук. В результате получился такой перекастрированный недо линк.
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, IT, Вы писали:
C>>Мейнстрим для глобальных баз данных это создание БД на OData сервере.
IT>Точнее мог бы быть мэйнстримом. Но когда кастрировали LINQ, чтобы сделать OData'у, то секанули не очень удачно и вместе с яцами отсекли всё, что висело ниже них. Т.е. ещё и ноги и кисти рук. В результате получился такой перекастрированный недо линк.
А как всегда, сначала секанули, а затем отращивают.
В любом случае OData неплохо развивается, в отличии от LINQ (твою привязанность к LINQ понять могу, здорово было сделано, но только для .NET/MSSQL).
Re[4]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, 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# со всеми вытекающими.
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: А как сейчас модно работать с БД из-под Windows?
> Клиент базы данных не вебе? Это что-то новое в дизайне приложений. Особенно в части защиты доступа к данным. > Даже SQL injection не нужен. Просто бери и грохай пользуйся
Как же бедный и несчастный rsdn.ru всё ещё жив...
Или он уже перестал жить в BD?
кстати, почему не работает форматирование сообщений?
Posted via RSDN NNTP Server 2.1 beta
Re[6]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Alex.Che, Вы писали:
AC>Как же бедный и несчастный rsdn.ru всё ещё жив...
Клиент базы данных RSDN нааходится на сервере, а не в вебе. В вебе находится клиент самого RSDN.
AC>кстати, почему не работает форматирование сообщений?
Да вроде всё работает.
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, IT, Вы писали:
C>>В любом случае OData неплохо развивается,
IT>Она не может неплохо развиваться, будучи с рождения ограниченной в рамках GET запроса браузера. Примитивные запросы — вполне, запросы к подготовленным методам на сервере — тоже возможно. Но говорить о каком-то серьёзном использовании OData в энтерпрайз приложениях — это вульгарный мазохизм.
То что OData работает в основном в рамках GET запросов это скорее плюс чем ограничение. Серверная часть — отдельная задача. Она легко тестируется в том числе на безопасность. Сложные запросы действительно придется готовить на сервере, но это тоже скорее плюс. Навредить такой базе данных извне будет сложнее.
В общем можно и нужно говорить о серьёзном использовании.
Re[6]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Аноним, Вы писали:
А>В общем можно и нужно говорить о серьёзном использовании.
Именно. Если говорить о серьёзном использовании, то работа с сервером у большинства WPF/SL девелоперов это одна из самых больших попаболей. Особенно, если они используют веб-сервисы. OData часть этой боли слегка снимает, но т.к. это не лечение болезни, а всего лишь болеутоляющее, то после превыкания попе всё равно по прежнему очень больно. В результате, если есть возможность народ переходит назад к двух звенке. Либо использует LINQ over WCF , в котором все ограничения OData сняты.
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, IT, Вы писали:
IT>OData часть этой боли слегка снимает, но т.к. это не лечение болезни, а всего лишь болеутоляющее, то после превыкания попе всё равно по прежнему очень больно. В результате, если есть возможность народ переходит назад к двухзвенке.
Если одни разрабатывают серверную часть, другие клиентскую, третьи web решение, четвертые делают анализ данных через Excel, то даже мысли переходить назад к двухзвенке не появится. OData для такой архитектуры. WCF тоже, но сегодня явно уступает по возможностям.
Re[10]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Cornetov, Вы писали:
IT>>Самому же коду без разницы где работать — на сервере приложений или на машине клиента. C>Не нужно глобальное решение -- флаг в руки. Но баги выгребать будет сложенее.
Странное понимание глобальности. Для меня глобальное решение — это код, которому без разницы где работать. Захочу помещу его на сервер, захочу — на клиента, а для того, чтобы выгребать баги — вызову его из тестов. Что не так не пойму
C>Ага! Зоопарк решений исключительно для .NET.
Ой, только не надо свои домыслы возводить в ранг истины. Как раз на .NET стало впервые возможным полноценное использование типизированного SQL со всеми последствиями. Например, для меня теперь словосочетание рефакторинг базы данных стало вполне привычным. Нужно только следовать двум правилам: использовать LINQ вместо прямого SQL и не использовать сохранённых процедур.
Если нам не помогут, то мы тоже никого не пощадим.
Re[11]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Cornetov, Вы писали:
IT>>>Самому же коду без разницы где работать — на сервере приложений или на машине клиента. C>>Не нужно глобальное решение -- флаг в руки. Но баги выгребать будет сложенее.
IT>Странное понимание глобальности. Для меня глобальное решение — это код, которому без разницы где работать. Захочу помещу его на сервер, захочу — на клиента, а для того, чтобы выгребать баги — вызову его из тестов. Что не так не пойму
Может и странное, но по моему глобальность это точно про переносимость кода, а про доступность и защищённость данных.
C>>Ага! Зоопарк решений исключительно для .NET.
IT>Ой, только не надо свои домыслы возводить в ранг истины.
Никаких домыслов, только факт что эти решения на платформе .NET.
IT>Как раз на .NET стало впервые возможным полноценное использование типизированного SQL со всеми последствиями. Например, для меня теперь словосочетание рефакторинг базы данных стало вполне привычным. Нужно только следовать двум правилам: использовать LINQ вместо прямого SQL и не использовать сохранённых процедур.
Я уже писал что не имею ничего против LINQ, но стоит ли изучать ее сейчас или все же лучше уделить внимание другим технологиям?
Re[12]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Cornetov, Вы писали:
C>Я уже писал что не имею ничего против LINQ, но стоит ли изучать ее сейчас или все же лучше уделить внимание другим технологиям?
Linq в его общем смысле стоило изучать еще в 2007/2008 году, и конечно же и сейчас. Если говорить о конкретно разных проектах linq to databases (linq2sql, EF, linq2db), то видимо это зависит от конкретного проекта на работе. Лично на всех моих последних проектах linq2db вписывался отлично, и я сейчас боюсь представить если вдруг придется работать без него.
Re[12]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Cornetov, Вы писали:
C>Может и странное, но по моему глобальность это точно про переносимость кода, а про доступность и защищённость данных.
Как мы видим локально глобальность может пониматься по разному, поэтому не стоит её использовать столь глобально.
C>Я уже писал что не имею ничего против LINQ, но стоит ли изучать ее сейчас или все же лучше уделить внимание другим технологиям?
Это зависит от задач и предпочтений. Для моих задач эта технология является настолько ключевой, что без её знания или хотя бы приличного представления о ней мы не принимаем людей на работу.
Кстати, многие даже работая ранее с LINQ, воспринимают тотальное отсутствие SQL с недоверием, а те, кто раньше пользовал EF, даже с неприятием. Но потом на других проектах испытывают без этого неудержимую ностальгию.
Если нам не помогут, то мы тоже никого не пощадим.
Re[11]: А как сейчас модно работать с БД из-под Windows?
IT>Ой, только не надо свои домыслы возводить в ранг истины.
А ты разве не это же самое делаешь?
IT>Как раз на .NET стало впервые возможным полноценное использование типизированного SQL со всеми последствиями. Например, для меня теперь словосочетание рефакторинг базы данных стало вполне привычным. Нужно только следовать двум правилам: использовать LINQ вместо прямого SQL и не использовать сохранённых процедур.
На счет последнего предложения. Представь что у тебя два проекта. Один на .НЕТ-е, другой на Джаве. И нужен этим приложениям один и тот же запрос. Будешь плодить запросы на разных технологиях?
А если три проекта или даже больше? Напомню, что в энерпрайзе с БД могут работать много разных приложений.
Re[13]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, IT, Вы писали:
IT> Кстати, многие даже работая ранее с LINQ, воспринимают тотальное отсутствие SQL с недоверием, а те, кто раньше пользовал EF, даже с неприятием. Но потом на других проектах испытывают без этого неудержимую ностальгию.
Но все же не будем забывать, что LINQ на сегодняшний день реализует лишь подмножество SQL и его диалектов. Поэтому о "тотальном отсутствии" в серьезных проектах говорить не приходится. И, я полагаю, в будущем это так и останется. Кесарю — кесарево.
Здравствуйте, IT, Вы писали:
IT> Я уже упоминал, что на сегодняшний день только одна вещь, не реализуемая на LINQ — иерархические CTE. И это всё! Всё остальное делается на LINQ и сопутствующих средствах влёт.
DML? Многострочный DML? DDL? Аналитика?
IT> Есть вещи, которые, например, в linq2db пока не реализованы. Но это не вопрос невозможности, это вопрос целесообразности.
Здравствуйте, wildwind, Вы писали:
IT>> Я уже упоминал, что на сегодняшний день только одна вещь, не реализуемая на LINQ — иерархические CTE. И это всё! Всё остальное делается на LINQ и сопутствующих средствах влёт. W>DML?
Не вопрос.
W>Многострочный DML?
Поясни.
W>DDL?
Легко.
W>Аналитика?
Первый раз слышу. Хотя нарисовать хелперов для всяких статистик и аналитик без проблем. Для этого даже не надо каких-то библиотек. Всё делается за пару минут на коленке. LINQ не об этом, а о том, чтобы SQL стал типизированным.
IT>> Есть вещи, которые, например, в linq2db пока не реализованы. Но это не вопрос невозможности, это вопрос целесообразности. W>Вот и я о том же, о целесообразности.
Что касается целесообразности, то всяко разная фигня типа DROP TABLE сначала проверяется именно на целесообразность, а уже потом потом добавляется в библиотеку. Кстати, на очереди TRUNCATE TABLE. До сих пор обходились хелпером, но не вижу причин не добавить эту команду в библиотеку.
Если нам не помогут, то мы тоже никого не пощадим.
Re[17]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Олег К., Вы писали:
ОК>Я бы вообще поставил вопрос целесообразности linq2db ибо она нарушает software engineering principles. Кто-то об этом не задумывается (включая автора), а мне, как purist-у, сложно это принять.
Ну-ка, ну-ка. Какие это ваши мягкотоварные инженерные принципы нарушает linq2db?
Если нам не помогут, то мы тоже никого не пощадим.
Re[15]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, 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>Я же только что объяснял, что если у вас один запрос на несколько проектов, то у вас что-то не так с несколькими проектами.
Я тебе уже привел пример с фронт эндом и репортами который ты проигнорировал.
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>Блин, чувак, ну не стоило скатываться на персоналии. До сих пор ты производил впечатление вменяемого собеседника и вдруг нате вам — я Д'Артаньян, а вы все немытое быдло
Слушай, я не скатывался. Вот без лести тебе скажу, что считаю тебя одним из немногих профи на этом сайте. Но и на старуху бывает проруха. Я не согласен с некоторыми твоими утверждениями и не хочу быть политкорректным.
Re[16]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Олег К., Вы писали:
ОК>Я тебе уже привел пример с фронт эндом и репортами который ты проигнорировал.
Не могу найти, где я это проигнорировал.
IT>>Т.е у тебя несколько приложений делают одно и тоже? Может быть имеет смысл задуматься о? ОК>Смотри выше. Это как в аппликейшн коде. Данные у тебя одни, а презентаций этих данных может быть много.
Это очередное заблуждение, которое красиво выглядит только в теории. На практике никакх много презентаций одних и тех же данных не бывает. Любая презентация, если она не полная копия предыдущей требует данные хотя бы чуть-чуть, но в другом виде.
IT>>Вполне может быть. Только здесь есть два момента. Либо мы говорим о повтоно используемых компонентах, либо мы плавно переходим к повторно используемому коду в бизнес логике. ОК>Так "вполне может быть" или "Т.е у тебя несколько приложений делают одно и тоже? Может быть имеет смысл задуматься о?"
Ещё раз. Вполне может быть. Только здесь есть два момента. Либо мы говорим о повтоно используемых компонентах, либо мы плавно переходим к повторно используемому коду в бизнес логике.
IT>>По первому всё просто. Это должно быть реализовано ввиде повторно используемого компонента, где запрос, та-да, будет реализован один раз. ОК>Ну и как ты сделаешь это в случае Джавы и Шарпа как я уже спросил выше?
Да никак. Джаве — джавово, шарпу шарпово. С вероятностью где-то в 100% двум разным приложениям, делающим разные вещи понадобятся совершенно разные запросы. Если же им потребуется результат работы одного сервиса, то это и должен быть один сервис. Клепать сервисы с помощью спроков, наверное можно, но это уже из серии садомазо. Это не ко мне.
IT>>Второе — один из признаков незрелости архитектора приложения. Повторно используемая бизнелогика — это мифологема типа древние укры выкопали Чёрное море. В теории да, но на практике очень геморно. Одно из свойств бизнес логики её постоянная изменяемость. Если завтра изменятся требования к одной части приложения, исользующей общий запрос в части общего запроса, то встанет дилема — либо написать новый запрос, либо обратиться к проматери всех парадигм — флажговому программированию, т.е. трансформировать нормальный код в говно код.
ОК>Я тебе об этом и говорю.
Сохранённых процедур это касается в полной мере.
ОК>Пафоса нету. Говорить не хочу, но мне интересно было бы узнать сколько таблиц в базе этого сайта и в базах ведущих американских банков (те базы с которыми тебе довелось поработать, то есть).
На сайте где-то с полсотни. В обычном приложении около сотни двух, видел и больше. Тенденция очень простая — чем хуже дизайн, тем больше в приложении таблиц. Но меня количество таблиц как-то не особо смущает. Сколько надо, столько пусть и будет. К чему это ты вообще?
ОК>Довелось работать над несколькими проектами одновременно в одном отделе.
И? Мне доводилось работать над несколькими проектами в одной команде. Даже во мне самом. В чём проблема?
ОК>Я этого не отрицаю, но сама база в виде хранимых процедур уже и есть "повторно используемый компонент" который можно без проблемы вызвать из любого языка программирования. Дальше, ты мыслишь так, что в один момент все изначально продумывается и затем пишется код. На деле же происходит эволюция системы, придумываются новые бизнес идеи и реализуются.
Сервисы в БД — это мазохизм. Ни отладчика, ни средств навигации по коду, ни средств рефакторинга. Некоторые базы типа Sybase вообще теряют контекст, если вызвать из одной процедуры другую. Языковые средства стары как какашки мамонта. Сам язык нетипизированный, пиши что хочешь, а потом лови в рантайме, если повезёт создать удачный сценарий. Можно легко грохнуть или переименовать таблицу и никто этого не заметит до падения системы в продакшине. Ты правда считаешь это самой перспективной технологией в мире?
ОК>Ну и ты не можешь плодить сервисы на каждый чих.
Пложу ровно столько сколько мне нужно, но гораздо меньше, чем ты думаешь.
ОК>Я согласен что БД должна возвращать данные а презентацией должен заниматься клиентский код, но позволю себе расширить твое утверждение. То что естественно для базы должно делаться на базе. Остальное — выше по стэку.
Ну наконец-то.
Если нам не помогут, то мы тоже никого не пощадим.
Re[19]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, 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. Почему код на Си шарпе лезет во внутренности нижележащего уровня (запросы)?
Re[20]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, wildwind, Вы писали:
W>А почему везде литералы, а не параметры?
Потому что в исходном коде литералы, а не параметры. Что написал, то и получил. Есть ещё дополнительный параметр, который все параметры генерирует как литералы. Полезен для отладдки, особенно на серверах, где объявить переменную прямо в тексте запроса нельзя.
Если нам не помогут, то мы тоже никого не пощадим.
Re[22]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, hrensgory, Вы писали:
H>О большинстве проектов, в которых хранимки декларировались как "единственные "точки входы" через которые ты можешь что-то получить от базы" у меня лично остались крайне неприятные воспоминания.
Вот! Послушайте умного человека!
Если нам не помогут, то мы тоже никого не пощадим.
Re[21]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Олег К., Вы писали:
ОК>Итак, на нижнем уровне стэка у тебя есть база, язык которой SQL. Уровнем выше у тебя код на Си шарпе. Теперь вопросы.
ОК>1. Почему код на Си шарпе должен знать implementation details нижележащего уровня (структура БД)? ОК>2. Почему код на Си шарпе лезет во внутренности нижележащего уровня (запросы)?
На мой взгляд спор в текущей дискуссии надо разделить на два отдельных вопроса:
1) Инкапсуляция
2) Хранимые процедуры vs Linq
По поводу инкапсуляции. Во-первых, как уже упоминалось, всякие сортировки и пейджинги — это не implementation details, это бизнес-логика. Во-вторых, никто лично вам не мешает выделить DAL для повышения инкапсуляции, структуризации, повторного использования. На позапрошлом проекте я так и делал, использовал linq2db, но при этом по-старинке выделял DAL. Если вы хотите, чтобы одинаковые запросы выполнялись на разных клиентах — пожалуйста, можно сделать веб-сервис, который внутри будет использовать linq. Кстати, то "нарушение инкапсуляции" здесь очень сильно играет на руку в плане рефакторинга и find usages.
По поводу Хранимых процедур vs Linq.
Я примерно 9 лет работал с хранимыми процедурами. Последние годы работаю с linq2db. Т.е. сравнить могу.
У хранимых процедур на мой взгляд две основные проблемы — отладка и рефакторинг. И если с отладкой еще можно примириться, благо некоторые IDE предоставляют отладку хранимых процедур, то рефакторинг становится либо невозможным, либо превращается в кошмар и вылезающие в run-time баги.
Хранимые процедуры, на мой взгляд, должны использовать только тогда, когда они совершенно необходимы, в каких-то конкретных частях проекта, но не как основной инсрумент работы с БД.
Когда я думаю о том, что в будущем я могу попасть на проект, где вся работа с БД опять будет на хранимых процедурах, у меня по рукам пробегают мурашки.
Re[22]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, MozgC, Вы писали:
MC>Когда я думаю о том, что в будущем я могу попасть на проект, где вся работа с БД опять будет на хранимых процедурах, у меня по рукам пробегают мурашки.
Вот! Послушайте ещё одного умного человека!
Если нам не помогут, то мы тоже никого не пощадим.
Re[20]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, IT, Вы писали:
IT>Главное требование к GetCustomerByID — это гибкость такого код. Такой код должен быть всегда готов к изменению. Завтра ко мне придёт BA и скажет, что вот здесь вот этот фактор надо бы ещё домножить на вот это число из вот этой таблицы и я должен буду быстро и, главное, не ломая ничего вокруг внести изменения. При этом у меня могут поплыть все запросы в БД. Если я начну говорить о том, что этого сделать нельзя потому что у меня уже "well defined interface к базе данных" и его ломать никак нельзя, то на меня будут смотреть либо как на идиота, либо вообще уволят и будут правы. Главное качаество бизнес кода — это возможность его быстро менять под новые требования, причём так, чтобы после этих изменений он оставался готовым к новым.
Скажите, а как решить поставленную задачу при наличии тех же требований, в случае если GetCustomerByID — это класс/компонент/метод и т.п. реализованный на C# с использованием LINQ? На мой взгляд варианта два. Но прежде всего нужно разобраться с существующей реализацией и понять насколько новые изменения затронут имеющийся C# код. На основании проведенного исследования необходимо принять решение — сделать изменения в классе/компоненте/методе и т.п и автоматом распространить их на остальной код, где так же может что-то поплыть, либо реализовать новый класс/компонент/метод на C# и LINQ. И с этой точки зрения хранимая процедура ведет себя аналогично, нужно понять влияние изменений на существующий код и выбрать правильное решение об изменении, либо создании новой процедуры.
Re[22]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, MozgC, Вы писали:
MC>Я примерно 9 лет работал с хранимыми процедурами. Последние годы работаю с linq2db. Т.е. сравнить могу. MC>У хранимых процедур на мой взгляд две основные проблемы — отладка и рефакторинг. И если с отладкой еще можно примириться, благо некоторые IDE предоставляют отладку хранимых процедур, то рефакторинг становится либо невозможным, либо превращается в кошмар и вылезающие в run-time баги. MC>Хранимые процедуры, на мой взгляд, должны использовать только тогда, когда они совершенно необходимы, в каких-то конкретных частях проекта, но не как основной инсрумент работы с БД.
А вы можете перечислить пожелания или требования к функционалу рефакторинга БД? Как показывает практика, в большинстве случаев разработчикам достаточно кнопки с функциональностью схожей в C# проектах, которая вызывается через Refactoring -> Rename (F2).
Re[22]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, IT, Вы писали:
IT>Почему ты решил, что я вообще буду что-то писать на SQL? SQL будет сгенерирован используемым мной инструментов в том виде, в котором мне нужно.
А в случае нормализации\денормализации много кода на C# переписать придется? Маппинг таблиц на классы в linq2db достаточно гибок, чтобы изолировать от этих изменений?
Re[21]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Olaf, Вы писали:
O>Скажите, а как решить поставленную задачу при наличии тех же требований, в случае если GetCustomerByID — это класс/компонент/метод и т.п. реализованный на C# с использованием LINQ?
Всмысле переписать существующий код на LINQ?
Если нам не помогут, то мы тоже никого не пощадим.
Re[23]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, artelk, Вы писали:
A>А в случае нормализации\денормализации много кода на C# переписать придется? Маппинг таблиц на классы в linq2db достаточно гибок, чтобы изолировать от этих изменений?
Мы в текущем проекте с linq2db массируем и жонглируем таблицами и колонками как хотим. С ХП это было бы невозможно (точнее возможно, но потраченного времени и багов было бы на порядок+ больше). Правда стоит отметить, что у нас поверх модели данных есть еще объектная модель (более приближенная к бизнесу), и бизнес-логика работает в основном с этой объектной моделью. Это позволяет инкапсулировать изменения. Т.е. при рефакторинге БД мы чиним внутренности объектной модели (иногда это простейшее обновление маппинга), а остальной код, который работает с этой объектной моделью не меняется.
Re[23]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Olaf, Вы писали:
O>А вы можете перечислить пожелания или требования к функционалу рефакторинга БД? Как показывает практика, в большинстве случаев разработчикам достаточно кнопки с функциональностью схожей в C# проектах, которая вызывается через Refactoring -> Rename (F2).
Да вроде полный набор:
Переименование, изменение типа, добавление, удаление таблиц и колонок.
Перенос таблиц в другие схемы
Объединение или разделение таблиц.
Re[22]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Olaf, Вы писали:
O>>Скажите, а как решить поставленную задачу при наличии тех же требований, в случае если GetCustomerByID — это класс/компонент/метод и т.п. реализованный на C# с использованием LINQ?
IT>Всмысле переписать существующий код на LINQ?
Я хотел спросить, что нужно сделать если у вас есть GetCustomerByID реализованный на C# и LINQ, а перед вами стоит задача "вот здесь вот этот фактор надо бы ещё домножить на вот это число из вот этой таблицы"? Пытаюсь понять какие преимущества даст ваш подход перед процедурным в данном случае.
Re[22]: А как сейчас модно работать с БД из-под Windows?
Поскипана куча букв не имеющих отношения к вопросу.
ОК>>Итак, на нижнем уровне стэка у тебя есть база, язык которой 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);
}
}
}
}
}
У тебя не только Си Шарповский код дублирует структуру базы, но и полагается на внутренности самой базы!
З.Ы. На вопросы ты так и не ответил! Потому что не можешь ответить!
Re[23]: А как сейчас модно работать с БД из-под Windows?
H>>О большинстве проектов, в которых хранимки декларировались как "единственные "точки входы" через которые ты можешь что-то получить от базы" у меня лично остались крайне неприятные воспоминания.
IT>Вот! Послушайте умного человека!
Да ты ведь даже не понял его ответа! Хрен горы согласился с тем, что linq2db нарушает инкапсуляцию базы, но тем не менее, по его мнению, если технология удобна, то почему бы не плюнуть на философию и тупо не использовать ее в проекте? Я, в принципе, согласен с таким утверждением, но лично мне, как purist-у, не просто такое (ORM фреймворки) принять.
Re[23]: А как сейчас модно работать с БД из-под Windows?
MC>>Когда я думаю о том, что в будущем я могу попасть на проект, где вся работа с БД опять будет на хранимых процедурах, у меня по рукам пробегают мурашки.
IT>Вот! Послушайте ещё одного умного человека!
Удобство не отменяет филосовских проблем с технологией! О чем я тебе уже который пост говорю.
Re[24]: А как сейчас модно работать с БД из-под Windows?
O>>Пытаюсь понять какие преимущества даст ваш подход перед процедурным в данном случае.
IT>Не перед процедурным, а перед текстуальным представлением SQL. В моём распоряжении все средства, доступные C#: типизация, навигация, рефакторинги, приличный отладчик. Любое ломающее изменение в БД у меня сразу ломает код. Пока я с этим не разберусь, моё приложение не собирается. В случае с текстуальным SQL я могу сколь угодно много его менять и словить проблему только в рантайм в продакшине.
Ну а неправильные запросы как ты отлаживаешь? Свои и чужие. Речь сейчас о Си шарпе, если что.
Re[22]: А как сейчас модно работать с БД из-под Windows?
MC>По поводу инкапсуляции. Во-первых, как уже упоминалось, всякие сортировки и пейджинги — это не implementation details, это бизнес-логика.
А бизнес логика это что ли не implementation details?
MC>Во-вторых, никто лично вам не мешает выделить DAL для повышения инкапсуляции, структуризации, повторного использования. На позапрошлом проекте я так и делал, использовал linq2db, но при этом по-старинке выделял DAL. Если вы хотите, чтобы одинаковые запросы выполнялись на разных клиентах — пожалуйста, можно сделать веб-сервис, который внутри будет использовать linq. Кстати, то "нарушение инкапсуляции" здесь очень сильно играет на руку в плане рефакторинга и find usages.
Как бы ты там не повышал инкапсуляцию в клиентском коде, инкапсуляция базы-то нарушена!
Re[2]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, sushko, Вы писали:
S>>Вопрос: а какой сейчас есть мейнстримовый путь работы с базами данных? Ну, например, из MSVisualC или из любого другого средства разработки "общего характера"?
IT>Если есть возможность использовать .NET, то только LINQ и никаких древних какашек мамонта типа ODBC.
В разработках под .NET также можно использовать: System.Data.Odbc ( https://msdn.microsoft.com/en-us/library/system.data.odbc(v=vs.110).aspx ).
Так — в чём же проблема? В религии?
Может просто вериться, что раз LINQ появился позже, то он лучше
Re[23]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Олег К., Вы писали:
ОК>Да? А вот это что такое?
А вот что это такое?
ОК>У тебя не только Си Шарповский код дублирует структуру базы, но и полагается на внутренности самой базы!
Ну дублирует и что? Если ты думаешь, что это как-то сильно напрягает, то ты ошибаешься. Структура классов генерируется по базе одним нажатием кнопки. Мы даже наследование от интерфейсов автоматизировали. Если видим, что в таблице есть поля, например, EffectiveDate и ExpirationDate, то тут же дабвляем классу наследование от какого-нибудь IEffectible. Используем комментарии к полям и таблицам в базе. Если видим там наличие текста [Obsolete], то добавляем такой атрибут к классу/свойству. В общем, напрягов абсолютно никаких. У нас в солюшине есть ещё чисто датабазный проект, который dbmdl. Вот с ним проблем куда больше. А это всё фигня.
По поводу полагается на внутренности самой базы ничего не понял.
ОК>З.Ы. На вопросы ты так и не ответил! Потому что не можешь ответить!
Ты вопрос сформулируй сначала внятно. А то ты уже несколько раз меня упрекнул в том, что я на что-то там не ответил, но при этом забыл сказать на что именно.
Если нам не помогут, то мы тоже никого не пощадим.
Re[25]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Олег К., Вы писали:
ОК> Вот простейший пример: запрос пишется на другом языке — Си Шарп или Джава — и чтобы его проверить, нужно скомпилировать код и проранать его. Для сравнения, запросы на сиквеле можно сразу же проранать в менеджмент студии. Меньше телодвижений. Точно также и отладка. Надо получить созданный сиквел и проранать его в студии если что-то непонятно. Не забываем, что нижележащий инструмент все-таки разговаривает на сиквеле.
Я ждал именно этого сообщения. Апологетам SQL только на это и остаётся напирать. Потому что это единственное удобство, якобы предоставляемое чистым сиквелом: написал запрос, тут же можно исполнить.
Однако, открой для себя хотя бы LinqPad: в нём можно сразу же писать linq-запросы к БД. Ни единой строчки маппинга таблиц БД на сущности C# писать не нужно! Они генерируются автоматически, моментально.
Re[4]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, IT, Вы писали:
IT>Это провайдер использовался одно время в BLToolkit, но не прижился. Всё современные БД уже имеют вполне зрелые нативные .net провайдеры, поэтому в ODBC необходимость отпадает. К тому же, ODBC нужно дополнительнос ставить, а для большинства провайдеров этого не нужно.
Да, нужно дополнительно ставить, но после этого у пользователя появляетюся возможности управления ODBC — data source (даже в плане оперативного тестирования канала связи с источником данных); кроме того — ODBC обладает универсальностью.
То есть — возможности применения этого самого data source НЕ ТОЛЬКО в приложениях на .NET, но и приложениях на C++ например.
IT>Ну вот, опять началось У меня сразу вопрос, у тебя есть хотя бы общее представление о LINQ?
Некоторое представление есть. В кода проекта моего приложения на C# — пишу SQL-подобное.
Хотя, в том же приложении, я могу написать строковый SQL-запрос (как обычно и делаю).
ИМХО, строковый натуральный SQL-запрос я могу отладить в MS SQL Server Management Studio, в отличие от LINQ.
Там же (в MS SQL Server Management Studio) — можно поиграть с запросом, видоизменить его или оптимизировать.
Риторический вопрос — что мне даст LINQ
IT>LINQ в принципе нельзя сравнивать с вещами типа ODBC. LINQ может работать поверх ODBC, ADO.NET, XML или просто объектов.
В смысле — работа с XML, как с объектами БД? Я верно понял?
IT>linq2db, linq2sql, EF и прочие — это LINQ провайдеры для баз данных. Каждый со своими достоинствами и недостатками. Например, философия (где там Олег К.?)
Я не придерживаюсь той точки зрения, что хранимые процедуры полезны. Лично я не пользуюсь хранимками — уже почти 10 лет.
Тем не менее, вполне пишу текстовые SQL-запросы в кодах (будто C#, или C++). Отлаживаю — в студии серверя. ЧЯДНТ?
IT>linq2db — это типизированный SQL интегрированный в C#. Филисофия EF (от которой постепенно отходят) — это жирный ORM, всемогутор, симулятор персистентности объектной модели приложения и поставщик прочих entity services. linq2sql — удачная проверка концепции, загубленная теми, кому эта технология в дальнейшем была отдана для поддержки и продвижения.
ИМХО всё это объединяет исполнимый код с кодом SQL-запроса. Не буду уповать на философию. Ключевой вопрос — как все это отлаживать???
Здравствуйте, AlexGin, Вы писали:
IT>>Это провайдер использовался одно время в BLToolkit, но не прижился. Всё современные БД уже имеют вполне зрелые нативные .net провайдеры, поэтому в ODBC необходимость отпадает. К тому же, ODBC нужно дополнительнос ставить, а для большинства провайдеров этого не нужно. AG>Да, нужно дополнительно ставить, но после этого у пользователя появляетюся возможности управления ODBC — data source (даже в плане оперативного тестирования канала связи с источником данных); кроме того — ODBC обладает универсальностью.
И что это даёт? Кроме того, что пользователь получает какую-то возможность, о которой он может и понятия не имеет.
AG>То есть — возможности применения этого самого data source НЕ ТОЛЬКО в приложениях на .NET, но и приложениях на C++ например.
Очень хорошо. Никто не мешает поставить это отдельно для C++. Лишать себя удобств работы с нативными провайдерами ради такой "мегафичи" я бы точно не стал. Например, поддерживает ли ODBC драйвер весь диалект конкретной БД? Есть ли там поддержка BulkCopy? И т.п.
AG>ИМХО, строковый натуральный SQL-запрос я могу отладить в MS SQL Server Management Studio, в отличие от LINQ.
У меня в Output Window каждый чих, генерируемый LINQ. Можно просто смотреть на SQL, можно скопировать Management Studio и отладить по вкусу. Едиснтвенная проблема — BulkCopy. Но она такая же проблема и без LINQ. Но linq2db поддерживает режим BulkCopy как Multiple Row Insert, т.е. можно временно переключиться и получить в Output Window полный лог работы приложения с БД. Дальше хоть обкопируйся, хоть оботлаживайся.
AG>Там же (в MS SQL Server Management Studio) — можно поиграть с запросом, видоизменить его или оптимизировать.
Это я в курсе.
AG>Риторический вопрос — что мне даст LINQ
В этой теме уже несколько раз вполне конкретно отвечали на этот вопрос. В частности, linq2db — это типизированный SQL интергированный в C#. В результате мы имеем строгую типизация вместо манипулиции текстовыми константами, навигацию по коду, все доступные рефакторинги, отладчик.
IT>>LINQ в принципе нельзя сравнивать с вещами типа ODBC. LINQ может работать поверх ODBC, ADO.NET, XML или просто объектов. AG>В смысле — работа с XML, как с объектами БД? Я верно понял?
Верно.
AG>Тем не менее, вполне пишу текстовые SQL-запросы в кодах (будто C#, или C++). Отлаживаю — в студии серверя. ЧЯДНТ?
Тебе знаком термин "Рефакторинг базы данных"? Большинство девелоперов, когда до них доходит что это такое падют в обморок или крутят пальцем у виска. Это одна из самых трудоёмких задач с непредсказуемым результатом. Если у тебя в коде нет ни строчки на SQL, а только LINQ, то задача рефакторинга БД лишь чуть сложнее рефакторинга обычного C# кода.
AG>Ключевой вопрос — как все это отлаживать???
Почему ты думаешь, что если мы используем LINQ, то мы не знаем или вообще не видим SQL. SQL у меня постоянно перед глазами. Разница лишь в том, что я не пишу его руками. Руками я пишу LINQ запросы, а SQL генерируется. Причём в human friendly виде, то хорошо отформатированный, со всеми входными параметрами, готовый к копированию в Management Studio и подробному анализу и отладке. Вот здесь на видео можно посмотреть как это происходит вживую.
Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, IT, Вы писали:
IT>Тебе знаком термин "Рефакторинг базы данных"? Большинство девелоперов, когда до них доходит что это такое падют в обморок или крутят пальцем у виска. Это одна из самых трудоёмких задач с непредсказуемым результатом. Если у тебя в коде нет ни строчки на SQL, а только LINQ, то задача рефакторинга БД лишь чуть сложнее рефакторинга обычного C# кода.
Термин слыхал, однако практически с этим не сталкивался. В основном рефакторинг — кодов приложения.
IT>Почему ты думаешь, что если мы используем LINQ, то мы не знаем или вообще не видим SQL. SQL у меня постоянно перед глазами. Разница лишь в том, что я не пишу его руками. Руками я пишу LINQ запросы, а SQL генерируется. Причём в human friendly виде, то хорошо отформатированный, со всеми входными параметрами, готовый к копированию в Management Studio и подробному анализу и отладке.
...интересно посмотреть...
IT>Вот здесь на http://blog.linq2db.com/2015/05/linq-crud-operations.html можно посмотреть как это происходит вживую.
Спасибо, великолепный материал! Посмотрю и поизучаю.
Попутный вопрос: у меня из MS Visual Studio есть: MSVS-2008 (team system) и MSVS-2013 (community edition) — что из них для этого подходит?
P.S. В этом видео имеется что-то новое, по крайней мере для меня!
Возможно, пригодится в будущем!
Здравствуйте, AlexGin, Вы писали:
AG>Термин слыхал, однако практически с этим не сталкивался. В основном рефакторинг — кодов приложения.
Это потому-что легче написать систему с нуля, чем рефакторить её начиная с БД.
AG>Попутный вопрос: у меня из MS Visual Studio есть: MSVS-2008 (team system) и MSVS-2013 (community edition) — что из них для этого подходит?
2013 точно подойдёт. 2008 если не ошибаюсь поддерживает только .NET FW 3.5, а нужно минимум 4.0.
Если нам не помогут, то мы тоже никого не пощадим.
Re[11]: А как сейчас модно работать с БД из-под Windows?
IT> для меня теперь словосочетание рефакторинг базы данных стало вполне привычным.
Стало? А раньше были проблемы? На ваших проектах автотесты покрывали не всю работу с базой?
Re[12]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Alexander Polyakov, Вы писали:
IT>> для меня теперь словосочетание рефакторинг базы данных стало вполне привычным. AP>Стало? А раньше были проблемы? На ваших проектах автотесты покрывали не всю работу с базой?
1. Когда ты приходишь на проект, где нужно рефакторить БД, то об автотестах там как правило никогда не слышали.
2. Автотесты — это для идеальных проектов, где из время, стоимость, качество можно без труда выбрать все три состаяляющих. Ну, или если это совсем крошечный проект.
Если нам не помогут, то мы тоже никого не пощадим.
Re[25]: А как сейчас модно работать с БД из-под Windows?
Продолжай. Смех без причины — признак, сам знаешь, кого.
ОК>>Хрен горы согласился с тем, что linq2db нарушает инкапсуляцию базы, но тем не менее, по его мнению, если технология удобна, то почему бы не плюнуть на философию и тупо не использовать ее в проекте? Я, в принципе, согласен с таким утверждением, но лично мне, как purist-у, не просто такое (ORM фреймворки) принять.
IT>Я тебе тут уже целый пост про твою философию написал, но ты так ничего и не понял, пурист ты наш. Объясняю ещё раз. На философию мне положить большой болт. Это самое последнее о чём нужно думать. Есть более важные вещи, такие как поддержка кода и организация рабочего процесса. Тряпочка для протирки монитора важнее, чем вся твоя философия. И заканчивай уже на это напирать. На меня это действует с совершенно обратным знаком.
Ну так ты начни писать еще в стиле Си — откажись от функций членов и сделай все переменные члены публичными. Тебе ж положить на философию большой болт.
IT>ЗЫ. Извини, но на патерны и прочий булшин у меня тоже передозировка. На одном из моих проектво был один дебил, который ходил с табличкой design pattern police. Своей философией и паттернами задолбал абсолютно всех. Там где он не мог применить никакого паттерна, он применял визитор паттерн. В конце концов, чувак этот в результате за неуспеваемость был разжалован из архитекторов в девелоперы. С тех пор у меня устойчивая аллергия на подобных филосовствующих придурков.
Ты опять присваиваешь мне свои фантазии!
Re[25]: А как сейчас модно работать с БД из-под Windows?
ОК>>Удобство не отменяет филосовских проблем с технологией! О чем я тебе уже который пост говорю.
IT>Всё, с философией завязываем.
Ну так ты и завяжи со своей философией, что в базе не должно быть бизнес логики. А то как-то однобоко получается. Есть твоя философия, которой следует придерживаться, а есть моя философия с которой следует завязать.
Заодно еще откажись от инкапсуляции в Си шарповом коде. Сделай все переменные члены публичными и откажись от функций членов!
Re[24]: А как сейчас модно работать с БД из-под Windows?
ОК>>Да? А вот это что такое?
IT>А вот что это такое?
Ты о чем, чувак? И почему вырезал вопрос где я тебя попросил показать где я, якобы, сказал, что "ты будешь писать на сиквеле?"
ОК>>У тебя не только Си Шарповский код дублирует структуру базы, но и полагается на внутренности самой базы!
IT>Ну дублирует и что? Если ты думаешь, что это как-то сильно напрягает, то ты ошибаешься. Структура классов генерируется по базе одним нажатием кнопки. Мы даже наследование от интерфейсов автоматизировали. Если видим, что в таблице есть поля, например, EffectiveDate и ExpirationDate, то тут же дабвляем классу наследование от какого-нибудь IEffectible. Используем комментарии к полям и таблицам в базе. Если видим там наличие текста [Obsolete], то добавляем такой атрибут к классу/свойству. В общем, напрягов абсолютно никаких. У нас в солюшине есть ещё чисто датабазный проект, который dbmdl. Вот с ним проблем куда больше. А это всё фигня.
Неважно вручную структура описана или автоматически сгенерирована. Лучше, конечно же, второе но не в этом суть. Главное что она есть и что запросы в Си шарповом коде знают о внутренностях базы. Но для тебя, ведь, есть только две философии. Та которая твоя и та которая неправильная.
IT>По поводу полагается на внутренности самой базы ничего не понял.
Все поняли а ты так ничего и не понял?
ОК>>З.Ы. На вопросы ты так и не ответил! Потому что не можешь ответить!
IT>Ты вопрос сформулируй сначала внятно. А то ты уже несколько раз меня упрекнул в том, что я на что-то там не ответил, но при этом забыл сказать на что именно.
Сформулировал внятно. Даже пронумеровал их. Это ты предпочел пропустить неудобные тебе вопросы мимо ушей.
Re[26]: А как сейчас модно работать с БД из-под Windows?
K>Я ждал именно этого сообщения. Апологетам SQL только на это и остаётся напирать. Потому что это единственное удобство, якобы предоставляемое чистым сиквелом: написал запрос, тут же можно исполнить. K>Однако, открой для себя хотя бы LinqPad: в нём можно сразу же писать linq-запросы к БД. Ни единой строчки маппинга таблиц БД на сущности C# писать не нужно! Они генерируются автоматически, моментально.
Очередной костыль. Родной язык базы — сиквел. Вместо этого писать те же самые запросы на Си шарпе лишь с одной целью — чтобы иметь возможность перенести их в Си шарповский код. Запросы те же, синтаксис только другой. Тебе не кажется это уродливым?
Re[26]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Олег К., Вы писали:
ОК>Ну так ты начни писать еще в стиле Си — откажись от функций членов и сделай все переменные члены публичными. Тебе ж положить на философию большой болт.
По-моему, всё в точности наоборот. Мне положить на философию, поэтому я могу выбирать самые современные инструменты. Ты со своей философией застрял даже не в стиле Си, а в T-SQL в стиле флажкового программирования.
Если нам не помогут, то мы тоже никого не пощадим.
Re[26]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Олег К., Вы писали:
ОК>Ну так ты и завяжи со своей философией, что в базе не должно быть бизнес логики. А то как-то однобоко получается. Есть твоя философия, которой следует придерживаться, а есть моя философия с которой следует завязать. ОК>Заодно еще откажись от инкапсуляции в Си шарповом коде. Сделай все переменные члены публичными и откажись от функций членов!
Да уже. Это какой-то фиерический пипец. В огороде бузина, а в Киеве дядька
Если нам не помогут, то мы тоже никого не пощадим.
Re[27]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Alexander Polyakov, Вы писали:
>>... сырым sql СУБД AP>LINQ лучше прожарен, чем SQL? Почему?
Это всего лишь общепринятая терминология. Сырым называют то, что ближе к железу, ОС, внутреннему устройству БД и т. п. А если сделаем обёртку/слой над этим чем-то, то уже не сырое.
Если используем SQL — это высокоуровневый доступ к БД. Если напишем хранимки, то sql становится сырым, низкоуровневым, а хранимки — более высоким уровнем.
LINQ-запросы тоже можно назвать сырыми. Ведь над ними тоже можно сделать обёртку.
Re[26]: А как сейчас модно работать с БД из-под Windows?
IT>>>На философию мне положить большой болт. Это самое последнее о чём нужно думать. Есть более важные вещи, такие как поддержка кода и организация рабочего процесса ОК>>Ну так ты начни писать еще в стиле Си — откажись от функций членов и сделай все переменные члены публичными. Тебе ж положить на философию большой болт. S>Подозреваю, если для решения некоторой конкретной задачи программирование в процедурном стиле (в стиле Си, как ты пишешь) без инкапсуляции, приватных методов и свойств позволит создать более компактный, выразительный, легко читаемый, тестируемый и поддерживаемый код, то Игорь без колебаний махнет рукой на все фенечки ООП. Для HelloWord или вычисления корней квадратного уравнения ты же станешь приватные методы писать правда (я утрирую конечно)?
Не стану.
S>Другой вопрос — даст ли переход на Си-стиль какой-нибудь профит? S>А вот от отказа от DAL Игорь, очевидно, профит получает.
При чем тут ДАЛ? Ты вообще понял о чем речь? База открыта, а ты мне тут про ДАЛ.
Ну и коли ты решил выступить его адвокатом, тогда объясни почему он выборочно так поступает? Дальше, объясни почему он впадает в истерику на справедливое, в принципе, замечание?
S>Твой же пуристический подход предполагает следование догмам независимо от того нужны ли они и продуктивны ли.
Это не так. Даже на сиквеле можно писать понятный и поддерживаемый код. Другое дело, что большинство не умеет. Соответсвенно у большинства будет код на Си шарпе не лучше кода на сиквеле.
Re[27]: А как сейчас модно работать с БД из-под Windows?
ОК>>Ну так ты начни писать еще в стиле Си — откажись от функций членов и сделай все переменные члены публичными. Тебе ж положить на философию большой болт.
IT>По-моему, всё в точности наоборот. Мне положить на философию, поэтому я могу выбирать самые современные инструменты. Ты со своей философией застрял даже не в стиле Си, а в T-SQL в стиле флажкового программирования.
Ты дальше своей Вижуал Студии ничего и не видешь.
Re[27]: А как сейчас модно работать с БД из-под Windows?
ОК>>Ну так ты и завяжи со своей философией, что в базе не должно быть бизнес логики. А то как-то однобоко получается. Есть твоя философия, которой следует придерживаться, а есть моя философия с которой следует завязать. ОК>>Заодно еще откажись от инкапсуляции в Си шарповом коде. Сделай все переменные члены публичными и откажись от функций членов!
IT>Да уже. Это какой-то фиерический пипец. В огороде бузина, а в Киеве дядька
Еще бы! По делу сказать ничего не можешь. Вместо этого ты устроил тут истерику на справедливое, в принципе, замечание.
Нравится тебе твой подход — пользуйся! Но того, что там есть фундаментальная проблема не отнять. И ты ведь даже не задумывался об этом до этого поста!
Re[24]: А как сейчас модно работать с БД из-под Windows?
A>>А в случае нормализации\денормализации много кода на C# переписать придется? Маппинг таблиц на классы в linq2db достаточно гибок, чтобы изолировать от этих изменений?
MC>Мы в текущем проекте с linq2db массируем и жонглируем таблицами и колонками как хотим. С ХП это было бы невозможно (точнее возможно, но потраченного времени и багов было бы на порядок+ больше). Правда стоит отметить, что у нас поверх модели данных есть еще объектная модель (более приближенная к бизнесу), и бизнес-логика работает в основном с этой объектной моделью. Это позволяет инкапсулировать изменения. Т.е. при рефакторинге БД мы чиним внутренности объектной модели (иногда это простейшее обновление маппинга), а остальной код, который работает с этой объектной моделью не меняется.
Ну то есть у вас подход "вначале поломаем, потом будем смотреть, что поломалось и затем уже чинить" вместо того чтобы вначале подумать, что делаете?
Re[28]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, sushko, Вы писали:
S>Вопрос: а какой сейчас есть мейнстримовый путь работы с базами данных? Ну, например, из MSVisualC или из любого другого средства разработки "общего характера"?
Почему "или"?
Когда можно и из того и и из другого и из третьего. Причем одновременно
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[24]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Олег К., Вы писали:
ОК> linq2db нарушает инкапсуляцию базы,... но лично мне, как purist-у, не просто такое (ORM фреймворки) принять.
Послушайте, ваши сообщения — прямо-таки живая иллюстрация к известной лекции академика Павлова "О русском уме". Вы доктринер, но это плохое качество для инженера.
Здравствуйте, Somescout, Вы писали:
S>Linq2DB умеет с работать с SQL Server filestream?
Если маппинг прописать, то можно работать с чем угодно.
Если это оно, то тут есть один маленький ньюанс. Здесь используется using для SqlFileStream объекта. Если нужна такая же функциональность, то нужно подумать в каком виде это лучше организовать. По идее работы на час, главное придумать в каком виде это должно быть.
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Olaf, Вы писали:
MC>>Переименование
O>Все объекты БД можно переименовать Refactor -> Rename (F2), причем переименовывается не только сам объект, но и все ссылки на него в связанных объектах и скриптах.
И даже в отрыжке вида
declare @whereClause nvarchar(200)
if @foo = 1
set @whereClause = @whereClause + ' and Foo = 1'
else
set @whereClause = @whereClause + ' and Bar = 1'
?
HgLab: Mercurial Server and Repository Management for Windows
Re[26]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, Нахлобуч, Вы писали:
O>>Все объекты БД можно переименовать Refactor -> Rename (F2), причем переименовывается не только сам объект, но и все ссылки на него в связанных объектах и скриптах.
Н>И даже в отрыжке вида Н>... Н>?
Переименовать можно только объекты БД (Таблицы, колонки, представления, ХП, функции и прочее). Поддержку работы с переменными обещали сделать в следующих версиях SSDT.
Re[24]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, IT, Вы писали:
IT>В том то и дело, что у меня нет GetCustomerByID. Я не создаю микрометодов с бизнес логикой. Даже миниметодов не создаю. Если в двух местах часть бизнес логики потребует GetCustomerByID, то я в двух местах напишу
IT>
IT>А когда мне в одном из мест понадобится внести изменение, то я даже не буду думать в каких там местах у меня похожий код. Я просто где надо напишу:
IT>
А как в linq2db по части кеширования? Он обеспечивает хотя бы First-level cache — ну вот как раз для случаев когда в пределах одной сессии вызываются оба запроса выше запрашивая объект с одним и тем же идентификатором? Иначе при всем удобстве "даже не буду думать в каких там местах у меня похожий код", эффективность такого подхода кажется будет невысока. Понятно, что оптимизация это дело не первое (и не второе ), интересут в принципе, есть ли поддержка кеширования "out-of-the-box" в linq2db.
Сейчас модны хитровыверты на функциональных языках, веб и мобильная разработка. Кто про БД заикнется значит замшелый старпер из мухосранска вылез.
Если нам не помогут, то мы тоже никого не пощадим.
Что ещё за клиентский код? Если ты про восемнадцатый слой в своей слоёной архитектуре, то ты ещё более безнадёжен, чем я думал. Но даже в этом случае никто не запрещает именно в твоём DAL использовать LINQ и скрывать детали как угодно. Или ты хочешь сказать, что детали можно скрыть только в сохранённых процедурах?
У меня сразу вопрос, у тебя есть хотя бы общее представление о LINQ?
, в котором все ограничения OData сняты.
