VD>>На мой взгляд у такого подхода много проблем. Точнее только они и есть. IT>Кроме семантического несоответствия больше никаких проблем.
Игорь, заведи тетрадочку
Как напишешь — будет интересно гемор-ноутсы почитать
IT>В твоём примере с процедурой? Так там у тебя нет ни DAL, ни BL. Только каша из TSQL.
Хорошо, приведи пример где не будет каши и где всё будет сделано правильно.
И если можно покажи там разделение на слои.
PS:
Не понял где там каша, вроде был один TSQL запрос
Здравствуйте, Tom, Вы писали:
VD>>>На мой взгляд у такого подхода много проблем. Точнее только они и есть. IT>>Кроме семантического несоответствия больше никаких проблем. Tom>Игорь, заведи тетрадочку
Я могу сделать хоть так, хоть сяк, хоть наперекосяк. Как скажешь, так и сделаю. А ты так можешь?
Tom>Как напишешь — будет интересно гемор-ноутсы почитать
Форум рядом, иди читай
Если нам не помогут, то мы тоже никого не пощадим.
IT>Я могу сделать хоть так, хоть сяк, хоть наперекосяк. Как скажешь, так и сделаю. А ты так можешь?
(( Я же серьёзно. Хочу понять как с твоей точки зрения будет правильно.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, VladD2, Вы писали:
VD>>Киберак с Рома — это классические ОРМ-щики. Они в основном разговаривают о распределенных когерентных кэшах и ООП. VD>>Их головы просто не настраиваются на разговор вне контекста объектов. Они так видят (с)
A>Влад, если бы ты не только писал, но и читал, ты бы понял, что мне не нравятся ORM. Но, видимо, не судьба.
Дело не в том что у него "одноразовые объекты для бедных" и он не понимает мощи ооп.
Проблема в том, что ооп не понимает почти никто, кроме программистов.
Выше я пытался рассказать о том как при разборе жалоб предметников выяснилось что они не поняли и не приняли классификацию атрибутов по объектам. При чем не классификация была плохая, просто вся нормативка шла в терминах атрибутов и для разных случаев были разные наборы атрибутов, и из-за большой сложности (сотни взаимосвязанных атрибутов) они привыкли строить срезы множества атрибутов, поперек объектов. Почему — не знаю Идеальный редактор который они хотели был эксель с сахаром, а не дерево объектов. Получалось, что объекты это абстракция над предметной областью чуждая ей. То есть в принципе они могли бы понять и проверить объектную модель, но она серьезно им мешала.
Та же проблема с моделью данных. Я бы с интересом посмотрел как ее можно решить генерацией. Те дба которых я видел просто хмыкнули бы и сказали что для оракла это просто невозможно.
Та же проблема с безопасностью. Какая степень дублирования нужна чтобы при отзыве прав с объекта бд транзитивно обновились все кеши объектов?
то есть мне не понятно как вы для себя решили проблему отображения объекты логики <-> сущности бд.
Здравствуйте, SleepyDrago, Вы писали:
SD>Выше я пытался рассказать о том как при разборе жалоб предметников выяснилось что они не поняли и не приняли классификацию атрибутов по объектам. При чем не классификация была плохая, просто вся нормативка шла в терминах атрибутов и для разных случаев были разные наборы атрибутов, и из-за большой сложности (сотни взаимосвязанных атрибутов) они привыкли строить срезы множества атрибутов, поперек объектов. Почему — не знаю Идеальный редактор который они хотели был эксель с сахаром, а не дерево объектов. Получалось, что объекты это абстракция над предметной областью чуждая ей. То есть в принципе они могли бы понять и проверить объектную модель, но она серьезно им мешала.
О, эту проблему решить очень просто Я лично разбираюсь в предметной области. У меня неплохие познание в финансах, логистике, торговле. Если разонравится программирование, будет чем занятся.
На самом деле всё довольно грустно. Дело даже не в том, что клиент не может описать то, что он хочет, дело в том, что клиент не знает что он хочет. Не знает по той простой причине, что не умеет предсказывать поведение программных систем даже на уровне "получится/не получится". Практика показывает что программисту выучить предметную область проще, чем клиенту — программирование. Такие вот дела.
SD>Та же проблема с моделью данных. Я бы с интересом посмотрел как ее можно решить генерацией. Те дба которых я видел просто хмыкнули бы и сказали что для оракла это просто невозможно.
На самом деле они, отчасти, правы. Но только отчасти. 90% запросов можно генерировать и даже если они будут абсолютно оптимальными, они будут очень близки к этому. Остальные 10% это запросы которые можно оптимизировать. Более того, из нужно оптимизировать. И я не за тотальную генерацию, я за то чтобы начать с генерации и переписать вручную только то, что необходимо переписать. В данном случае, хранимая процедура это ещё один уровень абстракции, ещё один контракт между уровнями. Если мне надо получить остаток склада, то я, с точки зрения логики, просто обязан считать его как сумму операций перемещения. Если я захочу оптимизировать, запоминать промежуточные результаты (остатки складов на начало каждого месяца) или ещё что-то, это всё останется внутри хранимки. В случае с Linq-подобными запросами, не будет единой точки, логика размазана по всему приложению, рефакторинг дорог.
SD>Та же проблема с безопасностью. Какая степень дублирования нужна чтобы при отзыве прав с объекта бд транзитивно обновились все кеши объектов?
На самом деле с правами доступа всё проще и придумано до нас До операции logout или её аналога эффективные права доступа пользователя не меняются.
Что касается кешей, то либо у нас кеш на сервере, где могут быть любые объекты и доступ к нему контроллируется отдельно, либо кеш на клиенте, где данные только для данного клиента. В целях безопасности, кеш можно чистить после выхода из системы.
SD>то есть мне не понятно как вы для себя решили проблему отображения объекты логики <-> сущности бд.
Не без ограничений обошлось, конечно. Скажем, тип данных для primary key для всех объектов фиксирован и одинаков. Я выбрал Guid, потому что данные в систему попадают отовсюду и таскать с сервера IDENTITY удовольствие сомнительное. Например, для списка валют, многие, при написании вручную, в качестве PK взяли бы трёхбуквенный код (UAH, RUR, USD). У меня это Guid, а трёхбуквенный код — один из столбцов. Как с точки зрения логики, так и с точки зрения производительности — несущественное изменение. Но такая унификация сильно упрощает жизнь. Ну и так далее, по мелочи.
Здравствуйте, adontz, Вы писали:
A>Не без ограничений обошлось, конечно. ..
Спасибо. Теперь я примерно представляю ограничения и границы применимости этого подхода.
Подход IT погуманнее будет к легаси БД, но там много "полунаписанных" инструментов, еше не прошедших серьезного испытания временем
Узнал для себя немало нового , так что спасибо Tom, что затеял это пожарище.
Здравствуйте, Tom, Вы писали:
IT>>Я могу сделать хоть так, хоть сяк, хоть наперекосяк. Как скажешь, так и сделаю. А ты так можешь? Tom>(( Я же серьёзно. Хочу понять как с твоей точки зрения будет правильно.
начинались первые попытки воплотить это на практике 6 лет назад. Сегодня это выглядело бы как-то так:
public class CustomerInfo
{
public string FirstName;
public string LastName;
}
public class CustomerManager
{
public CustomerInfo GetCusomerInfo(int @id)
{
return CustomerAccessor.CreateInstance().GetCusomerInfo(id);
}
}
public abstract class CustomerAccessor : DataAccessor
{
[SqlQuery(@"
SELECT FirstName, LastName
FROM Customer
WHERE ID_Customer=@id")]
public abstract CustomerInfo GetCusomerInfo(int id);
}
А завтра я хочу от всего этого избавиться и писать так:
public class Form1
{
private TextBox cusomerId;
private TextBox firstName;
private TextBox lastName;
public void MyButton_OnClick(object sender, EventArgs e)
{
try
{
int id = Convert.ToInt32(cusomerId.Text);
using (var db = new DbManager())
{
var q = (from c in db.Customer where c.ID = id select c).First();
firstName.Text = q.FirstName;
lastName. Text = q.LastName;
}
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
}
}
Одним словом, назад в будущее
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Tom, Вы писали:
IT>>В твоём примере с процедурой? Так там у тебя нет ни DAL, ни BL. Только каша из TSQL. Tom>Хорошо, приведи пример где не будет каши и где всё будет сделано правильно. Tom>И если можно покажи там разделение на слои.
Есть большая проблема в примерах архитектуреных решений. Маленькие примеры непоказательны, а в больших трудно разобраться, да и многие преимущества и недостатки неочевидны.
Tom>PS: Tom>Не понял где там каша, вроде был один TSQL запрос
Попробуй просто описать что метод делает. Не общее описание, а вкратце алгоритм, за что отвечают параметеры, что возвращается.
Здравствуйте, IT, Вы писали:
IT>public abstract class CustomerAccessor : DataAccessor IT>{ IT> [SqlQuery(@" IT> SELECT FirstName, LastName IT> FROM Customer IT> WHERE ID_Customer=@id")] IT> public abstract CustomerInfo GetCusomerInfo(int id); IT>} IT>[/c#]
А давно стало возможным так вопросы задавать? А то я как-то читал статью по BLT (2006 год) там такого не было.
Скажи, а как ты относишься к ХП (а то у тебя запрос в коде) и почему именно так.
IT>А завтра я хочу от всего этого избавиться и писать так:
IT> public void MyButton_OnClick(object sender, EventArgs e) IT> { IT> try IT> { IT> int id = Convert.ToInt32(cusomerId.Text); IT> using (var db = new DbManager()) IT> { IT> var q = (from c in db.Customer where c.ID = id select c).First();
IT> firstName.Text = q.FirstName; IT> lastName. Text = q.LastName; IT> } IT> }
Я думаю что одно из назначений DAL еще и в повышении повторного использовании кода. Один dal-метод может использоваться из разных мест в бизнес-логике. Не думаешь что такой вот подход с отказом от DAL будет провоцировать дублирование кода?
Здравствуйте, MozgC, Вы писали:
MC>А давно стало возможным так вопросы задавать? А то я как-то читал статью по BLT (2006 год) там такого не было.
запросы ***
PS. Может все-таки обсудим редактирование сообщений? Раз вы так опасаетесь разведения флейма, отказа от своих слов и т.д. (это точно не параноя и преждевременные опасения?), то ведь возможны варианты: к примеру возможность редактирование в течение небольшого времени после отправки сообщения или давать возможность редактирования старым участникам форума или людям с определенным рейтингом?
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, VladD2, Вы писали:
V>>>Именно, нестрогая, да еще и динамическая типизация. И не только у MS SQL, практически у всех популярных СУБД.
VD>>Осталось доказать это утверждение.
V>Доказать что?
Тебе не ясно значение слова "утверждение"?
Вот и докажи свое утверждение.
V>Что даже сохранённые запросы (или спроки) компиллируются динамически, и ты не узнаешь про проблемы до запуска запроса?
Какая прелесть "сохранённые запросы"?! Сам придумал, сам обсуждает.
Я уже не спрашиваю, что такое "спроки".
Какая разница что и когда компилируется? Статическая типизация — это когда типы выражений известны до выполнения. И для SQL-я это всегда так.
По-твоему зачем в таблицах описываются типы данных колонок?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Какая прелесть "сохранённые запросы"?! Сам придумал, сам обсуждает.
Не обязательно блистать невежеством, в один базах это называется "view", в других "сохранённый запрос".
VD>По-твоему зачем в таблицах описываются типы данных колонок?
Покажи мне типы тут:
select a+1 a1, b from c
Тип a1 какой?
Число, строка, дата?
Как насчёт того, что в джоинах по некоей паре полей мы можем (по ошибке или намеренно) связываться даже в случае несовместимых типов этих полей (например, строки и числа)?
VD>Статическая типизация — это когда типы выражений известны до выполнения. И для SQL-я это всегда так.
И что есть "выполнение" для СУБД? Выполнение конкретного запроса? А как насчёт статической проверки всего вообще до запуска любых запросов, т.е. до поднятия базы? Как ни крути, а нарваться на несоответствие типов при некоем касте мы можем зачастую только в "run-time", в случае везения — на юнит тестах.
Здравствуйте, MozgC, Вы писали:
MC>А давно стало возможным так вопросы задавать? А то я как-то читал статью по BLT (2006 год) там такого не было.
Года два как минимум. Абстрактные аксессоры сейчас доведены до состояния, когда фантазии чтобы ещё сделать уже не хватает.
MC>Скажи, а как ты относишься к ХП (а то у тебя запрос в коде) и почему именно так.
ХП тоже поддерживаются в лучшем виде. Для вызова ХП достаточно НЕ указать атрибут с SQL. Тогда будет сгенерирован вызов ХП соответствующий сигнатуре метода.
Также можно положить код SQL во внешний файл и подбирать его оттуда в зависимости от провайдера, если хочется.
MC>Я думаю что одно из назначений DAL еще и в повышении повторного использовании кода. Один dal-метод может использоваться из разных мест в бизнес-логике. Не думаешь что такой вот подход с отказом от DAL будет провоцировать дублирование кода?
Не знаю у кого как, а в моей практике эта повторность получается мизирной. А если всё-таки она нужна, то никто ничего не запрещает повторно использовать. На здоровье. А вот избавиться от мусора в виде path-through слоёв было бы очень заманчиво. Я пока интенсивно этот подход не использовал, так что сам не знаю что из этого выйдет, но пока никаких проблем не вижу.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Не знаю у кого как, а в моей практике эта повторность получается мизирной. А если всё-таки она нужна, то никто ничего не запрещает повторно использовать. На здоровье. А вот избавиться от мусора в виде path-through слоёв было бы очень заманчиво. Я пока интенсивно этот подход не использовал, так что сам не знаю что из этого выйдет, но пока никаких проблем не вижу.
Скажи, а какой бы подход в работе с БД ты бы выбрал в случае не-MSSQL? Я так понимаю что как раз твой BLT?
Если нам не помогут, то мы тоже никого не пощадим.
Идеальный редактор который они хотели был эксель с сахаром, а не дерево объектов. Получалось, что объекты это абстракция над предметной областью чуждая ей. То есть в принципе они могли бы понять и проверить объектную модель, но она серьезно им мешала.
, так что спасибо Tom, что затеял это пожарище.
