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

IT>>Ну так в чём тогда проблема? Объективная реальность
C>Хочется чтоб всё быстро работало

Сделай чтоб работало быстро

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

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

A>>>Ты не прав.
G>>В чем?
G>>У вас проверки RLS не в коде?

A>Да, они в хранимках.

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

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

A>ИМХО всё не так. Для GetById надо откуда-то взять этот самый Id. Отсутствие объекта это исключительная ситуация и никаким null тут и не пахнет.

Если этот Id получен от пользователя (как в случае с примером о теме форума, удаленной модератором, например), то отсутствие в БД того, чей Id якобы передал в запросе пользователь должно быть ожидаемой ситуацией, а не исключительной. Потому как в Id в этом случае, может быть вообще все что угодно , а пользователи — они разные бывают

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

KV>>Уточню, речь о row-level security, упомянутой gandjustas'ом или о чем-то ином?
C>У меня это object-level security. Естественно, это не отменяет security на операции.

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

KV>>Кстати, а что ты будет делать с атаками man-in-the-middle?
C>Так как обычно security каналов связи (HTTPS со строгой проверкой сертов).

Нифига себе у тебя "есстественный путь", которым SQL-сервер смотрит наружу , хотя это по нашему

C>Или ты что-то другое имеешь в виду?

Да нет, именно это

C>>>Скажи, и нравится тебе как работает Лотус?
KV>>Как пользователю — нет, но это никак не связано с его архитектурой. Как админу, в прошлом поддерживавшему инфраструктуру из 12-13 лотусовых серверов и пары тысяч клиентов — да, нравится. Как безопаснику — мне вообще ничего не нравится, так что не аргумент
C>Тем не менее, это подход очень глючный. Для email-серверов он ещё сгодится — нет особых ограничений на время и консистентность синхронизации.

Лотус — это не почтовый сервер. Более того, сама IBM уже не раз признавала, что именно как почтовик, оно получилось не очень.

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

C>>У меня это object-level security. Естественно, это не отменяет security на операции.
KV>Т.е. ты строишь в реляционной среде разграничение доступа на уровне объектов и утверждаешь, что это лучше, чем использовать для этого ОО-среду? Или у тебя ООБД?
У меня ORM. Т.е. объектная модель, построена на основе РБД.

KV>>>Кстати, а что ты будет делать с атаками man-in-the-middle?
C>>Так как обычно security каналов связи (HTTPS со строгой проверкой сертов).
KV>Нифига себе у тебя "есстественный путь", которым SQL-сервер смотрит наружу , хотя это по нашему
У меня не SQL-сервер, а моя система смотрит наружу.

KV>>>Как пользователю — нет, но это никак не связано с его архитектурой. Как админу, в прошлом поддерживавшему инфраструктуру из 12-13 лотусовых серверов и пары тысяч клиентов — да, нравится. Как безопаснику — мне вообще ничего не нравится, так что не аргумент
C>>Тем не менее, это подход очень глючный. Для email-серверов он ещё сгодится — нет особых ограничений на время и консистентность синхронизации.
KV>Лотус — это не почтовый сервер. Более того, сама IBM уже не раз признавала, что именно как почтовик, оно получилось не очень.
Я знаю, просто имею в виду саму область email-подобных решений.

Хотя, в принципе, в Лотусе репликация немного напоминает мой подход.

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

IT>>>Ну так в чём тогда проблема? Объективная реальность
C>>Хочется чтоб всё быстро работало
IT>Сделай чтоб работало быстро
Дык уже. С помощью идеологически неправильного антисоветского ORM

VD>Запросы не панацея — способ обработки данных. Его прекрасно можно использовать для обработки данных вместо дурацкого запаковывания всего и все в объекты и попыток использовать ООП для обработки данных.
Я чего то не понимаю где я писал что буду использовать ООП?

G>Да, у меня на все есть один ответ — DML. Разве его недостаточно для выполнения любой задачи по работе с данными?
Это уже кое что На сегодняшний день я знаю единственный язык полностью реализующий DML

G>К сожалению современные средства позволяют описывать только выборки, поэтому приходится немного постараться чтобы работа с данными была DML-подобной.
Интересно мне посмотреть такие попытки. Я себе их слабо представляю

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

G>>>При таком походе getById — это будет метод, который возвращает QueryObject c нужной выборкой. Это будет вспомогательный метод для BL.
Tom>>Открою тебе секрет. Разделения на BL/DAL/*** существуют только в голове у програмистов. Реально логика всегда размазана. Причём во всех единицах деплоймента.
G>
G>Открою тебе секрет, ни в одном моем проекте, которя я создавал от начала до конца такого не было.
Это фикция. Можем перейти к примерам (оставим розового слоника в покое ). Вот допустим выполняешь ты запрос:
update order set delayed = true where OrderDate < '...'
По твоему подобный запрос не реализует часть бизнес логики?
Если нет, тогда покажи мне пример на C# реализующий бизнес правило: Заказы не выполненые по любой причине в течении дня перевести в статус задержанные.

G>ЗЫ. Есдинственное что допускал из размазывания — перенесение некоторой части логики в функции\хранимки БД. Только с целью оптимизации.
Я это уже читал. Это фикция. С вовременных приложениях, когда одна из основных задач — работа с данными, бизнес логика в любом случае будет реализовываться через запросы к БД.
Конечно можно использовать ORM WAY но хрен редьки не слаще, а только геморней.

IT>>Это звучит примерно так: я не понимаю смысла разделения приложения на слои, поэтому предлагаю эти разделения сразу забыть. Да уж, чего только люди не придумают для оправдания собственных ошибок или непонимания сути обсуждаемых вещей.
Tom>Опять розовый слоник в вакууме

Поясню, я писал выше в сообщении но если ты пропустишь:

Можем перейти к примерам (оставим розового слоника в покое ). Вот допустим выполняешь ты запрос:
update order set delayed = true where OrderDate < '...'
По твоему подобный запрос не реализует часть бизнес логики?

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

G>>>>При таком походе getById — это будет метод, который возвращает QueryObject c нужной выборкой. Это будет вспомогательный метод для BL.
Tom>>>Открою тебе секрет. Разделения на BL/DAL/*** существуют только в голове у програмистов. Реально логика всегда размазана. Причём во всех единицах деплоймента.
G>>
G>>Открою тебе секрет, ни в одном моем проекте, которя я создавал от начала до конца такого не было.
Tom>Это фикция. Можем перейти к примерам (оставим розового слоника в покое ). Вот допустим выполняешь ты запрос:
Tom>update order set delayed = true where OrderDate < '...'
Tom>По твоему подобный запрос не реализует часть бизнес логики?
Tom>Если нет, тогда покажи мне пример на C# реализующий бизнес правило: Заказы не выполненые по любой причине в течении дня перевести в статус задержанные.
Сайчас это или foreach с объектами или SQL-запрос.
Если будет Linq или EF провайдер с поддержкой DML, то буду использовать только его.

G>>ЗЫ. Есдинственное что допускал из размазывания — перенесение некоторой части логики в функции\хранимки БД. Только с целью оптимизации.
Tom>Я это уже читал. Это фикция. С вовременных приложениях, когда одна из основных задач — работа с данными, бизнес логика в любом случае будет реализовываться через запросы к БД.
Вопрос в том как формировать такие запросы.
Linq сейчас позволяет это очень удобно делать в коде приложения, а не в хранимках или текстовых запросах в DAL, но только для выборок.

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

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

G>>>>>При таком походе getById — это будет метод, который возвращает QueryObject c нужной выборкой. Это будет вспомогательный метод для BL.
Tom>>>>Открою тебе секрет. Разделения на BL/DAL/*** существуют только в голове у програмистов. Реально логика всегда размазана. Причём во всех единицах деплоймента.
G>>>
G>>>Открою тебе секрет, ни в одном моем проекте, которя я создавал от начала до конца такого не было.
Tom>>Это фикция. Можем перейти к примерам (оставим розового слоника в покое ). Вот допустим выполняешь ты запрос:
Tom>>update order set delayed = true where OrderDate < '...'
Tom>>По твоему подобный запрос не реализует часть бизнес логики?
Tom>>Если нет, тогда покажи мне пример на C# реализующий бизнес правило: Заказы не выполненые по любой причине в течении дня перевести в статус задержанные.
G>Сайчас это или foreach с объектами или SQL-запрос.
Я написал пример. Можешь так же написать пример?

G>Если будет Linq или EF провайдер с поддержкой DML, то буду использовать только его.
Пример можно? И где вообще ты нашёл про поддержку DML в EF 2?

G>>>ЗЫ. Есдинственное что допускал из размазывания — перенесение некоторой части логики в функции\хранимки БД. Только с целью оптимизации.
Tom>>Я это уже читал. Это фикция. С вовременных приложениях, когда одна из основных задач — работа с данными, бизнес логика в любом случае будет реализовываться через запросы к БД.
G>Вопрос в том как формировать такие запросы.
G>Linq сейчас позволяет это очень удобно делать в коде приложения, а не в хранимках или текстовых запросах в DAL, но только для выборок.
Гед пример?

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


V>>Просто есть что-то не то в том, что по union можно в один столбец явно, или по ошибке склеить числовые и строковые данные, и никто не тебе ругнётся на это.

VD>Это вопрос строгости типизации. Есть СУБД которые не позволяют этого сделать. То что MS SQL имеет довольно слабую (и откровенно говоря дряхлую и кривую) систему типов — это проблемы Microsoft и от части Sybase, а не РСУБД.

Именно, нестрогая, да еще и динамическая типизация. И не только у MS SQL, практически у всех популярных СУБД.

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


V>>От ООБД можно взять "типизированность" кортежей. Да и вообще, побольше бы типизированности всего. Просто есть что-то не то в том, что по union можно в один столбец явно, или по ошибке склеить числовые и строковые данные, и никто не тебе ругнётся на это.
G>Да ну? Вообще-то компилятор запроса ругается при таком раскладе.

Какой компилятор?

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

L>Как ни прискорбно это сознавать, но большинство разработчиков работает в сфере т.н. enterprise-приложений, а уж в них получение чего-то по id, изменение этого и запись обратно в базу — гораздо более частая операция, чем массовые изменения в базе.

Какие руки (точнее головы), такие и решения. От области деятельности это зависит мало.
Если человек не может не смотреть на данные как на объект, то и появляются все эти GetById().

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

G>А кто мехает для операции "получение чего-то по id, изменение этого и запись обратно в базу" использовать один Update, а не SELECT+Update+ оптимистичная блокировка+identity map+навороченный кеш?

Менталитет.

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

L>Например то, что в этой цепочке присутствует пользователь и ему надо-таки что-то показать. Для этого и нужен GetById.

Это пользователь что ли вас по Id что-то просит получить?
Во как?!

Пользователь будет искать по чему угодно, только не по вашему id. Он скорее по дате поищит, или номеру договора. Получит список. В этом списке он ткнет мышкой. Тут конечно можно и GetById() вызвать, но зачем? Ведь часть данных уже выбраны. Можно выбрать только требуемые в данный момент. И select тут будет намного более удобнее. Зачем нам объект? Нам нужно содержимое договора (например).

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

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

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

G>>>>>>При таком походе getById — это будет метод, который возвращает QueryObject c нужной выборкой. Это будет вспомогательный метод для BL.
Tom>>>>>Открою тебе секрет. Разделения на BL/DAL/*** существуют только в голове у програмистов. Реально логика всегда размазана. Причём во всех единицах деплоймента.
G>>>>
G>>>>Открою тебе секрет, ни в одном моем проекте, которя я создавал от начала до конца такого не было.
Tom>>>Это фикция. Можем перейти к примерам (оставим розового слоника в покое ). Вот допустим выполняешь ты запрос:
Tom>>>update order set delayed = true where OrderDate < '...'
Tom>>>По твоему подобный запрос не реализует часть бизнес логики?
Tom>>>Если нет, тогда покажи мне пример на C# реализующий бизнес правило: Заказы не выполненые по любой причине в течении дня перевести в статус задержанные.
G>>Сайчас это или foreach с объектами или SQL-запрос.
Tom>Я написал пример. Можешь так же написать пример?
Я слегка прогнал.

Код будет такой:

var delayedOrders = from o in _orderRepository.Items
                    where o.OrderDate < xxx
                    select o;

Даже апдейты не нужны.

G>>Если будет Linq или EF провайдер с поддержкой DML, то буду использовать только его.
Tom>Пример можно? И где вообще ты нашёл про поддержку DML в EF 2?
Меня в EF интересует не eSQL и Object Services, а модель провайдеров и edm.
Сейчас в EF есть AST для представления запросов, в том числе числе insert\update\delete.
Но нету способов сформировать ast для DML, они формируются внутри при вызове SaveChanges в контексте.
Я сначала хотел написать методы-расширения для DML, но уперся в убогость самого средства описания модели данных — edm.
Ко второй версии EF обещают edm поправить, и если у них не будет провайдера с DML, то напишу свой.

G>>>>ЗЫ. Есдинственное что допускал из размазывания — перенесение некоторой части логики в функции\хранимки БД. Только с целью оптимизации.
Tom>>>Я это уже читал. Это фикция. С вовременных приложениях, когда одна из основных задач — работа с данными, бизнес логика в любом случае будет реализовываться через запросы к БД.
G>>Вопрос в том как формировать такие запросы.
G>>Linq сейчас позволяет это очень удобно делать в коде приложения, а не в хранимках или текстовых запросах в DAL, но только для выборок.
Tom>Гед пример?
Выше.

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

L>То о чем ты пишешь скорее относится не SOAP, но уж совсем не к SOA.

Нет.

L>Первое (SOAP) — описание формата сообщений и не более того.

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

L>Второе (SOA) — архитектурный подход к "разрезанию" логики приложений.

Этой архитектуре 100 лет в обед. Всю жизнь она называлась клиент-сервер. Весь остальной булшит из SOA — эо банальные принципы структурного программирования.