Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Это внешний по отношению к приложению сервис никак не связанный с осмыслением содержимого БД. Не понимаю, почему ты считаешь это бизнес-логикой приложения. G>>Любой код, который выполняет usecase приложения является бизнес логикой.
A>Является ли логика работы прав доступа NTFS частью бизнес-логики приложения работающего с файлами?
Ты доступа к этому не имеешь, поэтому разницы нету как называть.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, kochetkov.vladimir, Вы писали:
A>>>Ты уточни о каких именно событиях говоришь, я тебе отвечу. KV>>Попытки доступа пользователя к данным, на которые у него нет прав, например.
A>Такая проблема на практике не стоит,
Угу
Области, которые
необходимо рассмотреть, включают:
<bla-bla-bla>
c. попытки несанкционированного доступа, такие как: 1. неудавшиеся или отклоненные действия
пользователей;
2. неудавшиеся или отклоненные действия,
по отношению к данным и другим ресурсам;
Это выдержка из международного стандарта ISO/IEC FDIS 17799 "Информационные технологии — Методики безопасности — Практические правила управления информационной безопасностью" , раздел "Регистрация событий".
Плюс в ряде методик оценки рисков (OCTAVE например) и требований к финансовой отчетности (SOX) есть примерно такие контроли:
Проводится журналирование информации об операциях в ИС, включая события, относящиеся к информационной безопасности, в мере, достаточной для реконструкции и анализа процесса обработки данных и сопутствующих действий.
Хотя допускаю, что при ничтожности рисков возникновения в ИС инцидентов по ИБ, на эти контроли ориентироваться не стоит, но тем не менее...
A>Как следствие "попытки доступа пользователя к данным, на которые у него нет прав" исполняются с вероятностью "Пользователь угадал GUID".
Я писал о событиях отказа в доступе к этим данным.
A>Вот попыти выполнения запрещённых действий могут журналироваться, но это ловится выше DAL.
Здравствуйте, gandjustas, Вы писали:
A>>Является ли логика работы прав доступа NTFS частью бизнес-логики приложения работающего с файлами? G>Ты доступа к этому не имеешь, поэтому разницы нету как называть.
Здравствуйте, kochetkov.vladimir, Вы писали:
A>>Как следствие "попытки доступа пользователя к данным, на которые у него нет прав" исполняются с вероятностью "Пользователь угадал GUID". KV>Я писал о событиях отказа в доступе к этим данным.
Если запрашивается список объектов, то отказ доступа это отсутствие элемента в списке. Отследить что отфильтровалось не представляется возможным, да и не надо на самом деле.
Если запрашивается конкретный объект, от отследить факт невозврата объекта нет никакой проблемы.
A>>Вот попыти выполнения запрещённых действий могут журналироваться, но это ловится выше DAL. KV>Что есть "запрещенные действия"?
Изменение, создание, удаление данных. Что касается чтения, данные, к которым нет доступа, просто не видны.
Здравствуйте, IT, Вы писали:
G>>Вместо присвоений можно использовать NewExpression или сделать fluent-интерфейс с последовательным вызовом методов set(p => p.field == value)
IT>Мне new тоже больше импонирует.
Чем?
На мой взгляд у такого подхода много проблем. Точнее только они и есть.
В общем, хотелось бы услышать обоснование и примеры использования поглядеть.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Кроме семантического несоответствия больше никаких проблем.
На такую непосредственность и возразить-то сложно.
По-моему, семантическое несоответствие — это самое плохое, что можно было бы придумать. Приговор, я бы сказал.
IT>Для твоего примера как-то так:
IT>
IT>(from o in orders where o.OrderDate < xxx select o).Update(new order { delayed = true });
IT>
Ужас.
Потом, что такое "Update(new order { delayed = true })"? Из этого даже дерево выражений не получишь, так как оно строится только для лямбды. Тебе придется писать что-то вроде:
(from o in orders where o.OrderDate < xxx select o).Update(() =>new order { delayed = true });
Что выглядит еще более странно.
Если учесть, что иногда нужно использовать информацию из полей изменяемого объекта, то придется передавать его через параметр:
(from o in orders where o.OrderDate < xxx select o).Update(o =>new order { delayed = !o.delayed });
У пользователей будет ощущение, что информация о других значений из той же таблицы теряется.
Нехорошо, как-то.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Киберак с Рома — это классические ОРМ-щики. Они в основном разговаривают о распределенных когерентных кэшах и ООП. VD>Их головы просто не настраиваются на разговор вне контекста объектов. Они так видят (с)
Влад, если бы ты не только писал, но и читал, ты бы понял, что мне не нравятся ORM. Но, видимо, не судьба.
Здравствуйте, VladD2, Вы писали:
L>>То о чем ты пишешь скорее относится не SOAP, но уж совсем не к SOA.
VD>Нет.
Из того, ты отнес RPC и SOA к понятиям одного уровня, у меня сложилось именно такое ощущение.
Между тем SOA может прекрасно сосуществовать с тем же RPC, это понятия ортоганальные.
L>>Первое (SOAP) — описание формата сообщений и не более того.
VD>Спасибо, посвятил. Прежде чем бросаться мне что-то объяснять, сначала спроси не знаю ли я это. А по умолчанию вообще было разумно если бы ты считал, что я знаком тем о чем говорю.
Ну так объясни, как пожно сравнивать архитектурный подход с механизмом удаленного вызова. У меня это как-то слабо укладывается в голове.
L>>Второе (SOA) — архитектурный подход к "разрезанию" логики приложений.
VD>Этой архитектуре 100 лет в обед.
Кто-ж с этим спорит.
VD>Всю жизнь она называлась клиент-сервер. Весь остальной булшит из SOA — эо банальные принципы структурного программирования.
И да, и нет. То, что называют клиент-сервером, обычно относят к разделению на слои, горизонтальное деление (UI, бизнес-логика, данные + вариации).
SOA-же про то, как резать "вертикально", в иной плоскости, как стыковать разные бизнес-подсистемы. Это сильно разные вещи.
Здравствуйте, VladD2, Вы писали:
V>>Именно, нестрогая, да еще и динамическая типизация. И не только у MS SQL, практически у всех популярных СУБД.
VD>Осталось доказать это утверждение.
Доказать что? Что даже сохранённые запросы (или спроки) компиллируются динамически, и ты не узнаешь про проблемы до запуска запроса?
Здравствуйте, kochetkov.vladimir, Вы писали:
A>>Ещё в Presentation будет облом, во время попытки сконвертировать '||'6 в число. KV>Т.е. валидация входящих данных у тебя в презентационном слое?
Простейшая валидация формата данных (строка может быть сконвертирована в число), да.
IT>Логика, даже бизнес, и что давай теперь сюда ещё и императив притащим, раз пошла такая пьянка? Ты пойми простую вещь, DAL, BL и прочие слои придумали не просто так.
Игорь, обьясни мне идиоту, гед в моём примере DAL и где BL. Я что то в даннорм случае не могу уловить границу.
Здравствуйте, VladD2, Вы писали:
VD>Пользователь будет искать по чему угодно, только не по вашему id. Он скорее по дате поищит, или номеру договора. Получит список. В этом списке он ткнет мышкой. Тут конечно можно и GetById() вызвать, но зачем? Ведь часть данных уже выбраны. Можно выбрать только требуемые в данный момент.
Это зависит от того, что у вас за клиент. В случае веба click по договору приведет к открытию страницы договора, а на новой странице эта инфорация уже не будет доступна и запрашивать все рано придется.
VD>И select тут будет намного более удобнее. Зачем нам объект? Нам нужно содержимое договора (например).
Если схема данных один-в-один соответствует entity, то будет гораздо удобнее.
Если же DAL занимается каким-нибудь преобразованием из резалтсета в entity, то будет уже не так удобно.
Например, некоторые параметры не хранятся один-в-один в полях таблицы, а сериализуются в xml-ную колонку. Наличие DAL-а позволяет этот механизм хранения скрыть от бизнеса, что, имхо, очень удобно и позволяет очень просто дополнять поля сущности.
Здравствуйте, VladD2, Вы писали:
IT>>Кроме семантического несоответствия больше никаких проблем.
VD>На такую непосредственность и возразить-то сложно. VD>По-моему, семантическое несоответствие — это самое плохое, что можно было бы придумать. Приговор, я бы сказал.
Дык у остальных решений ни соотвествия, ни вменяемой реализации.
VD>Если учесть, что иногда нужно использовать информацию из полей изменяемого объекта, то придется передавать его через параметр:
Ты молодец, сам до всего догадался
VD>У пользователей будет ощущение, что информация о других значений из той же таблицы теряется. VD>Нехорошо, как-то.
Я пока других вариантов не вижу вовсе
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Tom, Вы писали:
IT>>Логика, даже бизнес, и что давай теперь сюда ещё и императив притащим, раз пошла такая пьянка? Ты пойми простую вещь, DAL, BL и прочие слои придумали не просто так. Tom>Игорь, обьясни мне идиоту, гед в моём примере DAL и где BL. Я что то в даннорм случае не могу уловить границу.
В твоём примере с процедурой? Так там у тебя нет ни DAL, ни BL. Только каша из TSQL.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Lloyd, Вы писали:
L>Ну так объясни, как пожно сравнивать архитектурный подход с механизмом удаленного вызова. У меня это как-то слабо укладывается в голове.
Тут есть одна проблема. Очень тяжело что-то объяснять тем кто не хочет понять. Тебе объяснить что-либо вообще почти не возможно. А я и так порядком подустал от этой дискуссии.
Объясняю на пальцах. Если не поймешь, значит не судьба... Дальше отвечать не буду.
До SOA MS насился с DCOM как с писанной торбой и уговаривал всех, что это лучшее средство создания сетевых приложений. Но со временем ребята из МС поняли, что ООП в распределенной среде — это вилы. Хранить ссылки на объекты через сетку — это идиотизм. Вот и решили откатиться к старым схемам когда сервер всего лишь производит обработку информации и возвращает результата клиенту. Но старую идею не продать. Вот и извернулись придумав новую "архитектуру". За одно придумали SOAP и много других базвордов. Многие (вот ты, например) купились на эту пиар. Но многие понимают, что никакой новой архитектуры не придумано, а все разговоры про компоненты не более чем булшит.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Дык у остальных решений ни соотвествия, ни вменяемой реализации.
Решение с функцией Set() мне больше нравится:
.Update(o => Set(o.Field, o.Field + 1))
VD>>У пользователей будет ощущение, что информация о других значений из той же таблицы теряется. VD>>Нехорошо, как-то.
IT>Я пока других вариантов не вижу вовсе
Согласен, что в рамках шарпа с решениями не ахти. Надо переходить на Немерле. В нем проблем не будет .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
L>>Ну так объясни, как пожно сравнивать архитектурный подход с механизмом удаленного вызова. У меня это как-то слабо укладывается в голове.
VD>Тут есть одна проблема. Очень тяжело что-то объяснять тем кто не хочет понять. Тебе объяснить что-либо вообще почти не возможно. А я и так порядком подустал от этой дискуссии.
Конечно же воздержаться от личных выпадов ты, увы, не можешь.
VD>Объясняю на пальцах. Если не поймешь, значит не судьба... Дальше отвечать не буду.
VD>До SOA MS насился с DCOM как с писанной торбой и уговаривал всех, что это лучшее средство создания сетевых приложений. Но со временем ребята из МС поняли, что ООП в распределенной среде — это вилы. Хранить ссылки на объекты через сетку — это идиотизм. Вот и решили откатиться к старым схемам когда сервер всего лишь производит обработку информации и возвращает результата клиенту. Но старую идею не продать. Вот и извернулись придумав новую "архитектуру". За одно придумали SOAP и много других базвордов.
Только одна маленькая неувязочка у них вышла: спецификация SOAP воявился лет за несколько до того, как о SOA начали говорить.
VD>Многие (вот ты, например) купились на эту пиар. Но многие понимают, что никакой новой архитектуры не придумано, а все разговоры про компоненты не более чем булшит.
На этот булшит повелись также IBM, Oracle, SAP. Один только Влад устоял.
P.S. Ничего личного, но имхо, стоит все-таки ознакомиться с SOA, хотя бы на таком уровне чтобы не мешать его в одну кучу с RPC.
Если нам не помогут, то мы тоже никого не пощадим.
