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

VD>Хорошим решением было бы сделать так:
VD>

VD>var delayedOrders = from o in orders
VD>                    where o.OrderDate < xxx
VD>                    select o;
VD>delayedOrders.Update(o => o.delayed = true);
VD>

VD>Но деревья выражений не поддерживают присвоений.

Вместо присвоений можно использовать NewExpression или сделать fluent-интерфейс с последовательным вызовом методов set(p => p.field == value)

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

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

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

G>Запросы вида insert ... select .. дейсвтительно не поддерживаются никак, короче дождусь второй версии EF, там буду думать.

Мне кажется проще EF в топку и создать свой провайдер. IT этим как раз занимается.

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

G>мы о сильно разных SOA разговариваем.

Я говорю о SOA.

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

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

G>>мы о сильно разных SOA разговариваем.

VD>Я говорю о SOA.
Угу, попытался найти ссылки про принципы SOA, которые еще называют Soa triangle, но половина у меня не открылась, а вторая половина показала маркетологический булшит.

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

VD>>Это именно запрос реализующий часть бизнес-логики.
VD>>И что?

Tom>То, что часть логики всегда будет реализована с использованием запросов БД.
Tom>И это не вселенское зло а нормальная ситуация.
Это очень даже правильно.

Tom>И в этом случае бизнес логика размазывается не только по слоям но и по компонентам деплоймента.
Tom>И это тоже не зло а нормальная ситуация.
А это совсем неправльно. Не надо БЛ прибивать гвоздями к базе. Пусть база занимается выполнением запросов, поддержанием целостности БД, конкурентным доступом и собственно хранением данных.
Запросы должны формироваться более высокими уровнями.

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

A>>Голословное утверждение. Каким образом чтение и последущий отсев данных улучшает безопасность по сравнению с запретом чтения?
KV>Зачем читать все, чтобы потом отсеять?

Ну как же, у тебя отсев ведь в BL, то есть после работы DAL

A>>И как оно работает?
KV>Вполне. И мне страшно подумать, как решались бы вопросы масштабирования и плохих каналов (плохой == < 10Мбит), если бы в лотусе не было этой "особенности". С чем собственно мы и столкнулись в 1С, и из-за чего с нее, в итоге, и свалили.

Владимир, несчастье 1С постигло и меня. При некоторой сноровке его вполне можно реплицировать. На самом деле репликация SQL Server (впрочем как и доставка журналов) достаточно толерантна к приложениям.

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

G>>>У вас проверки RLS не в коде?
A>>Да, они в хранимках.
G>От того что часть логики помещена в хранимки она логикой быть не перестает.
G>Зато теперь понятно почему тебе так не нравятся запросы, используя хранимки для CRUD использование запросов становится неудобным и почти ненужным.

Ещё раз. проверка доступа это не логика, это инфрастурктурный сервис. Логика приложения может выражаться в раздаче прав доступа, проверка — операция универсальная, никак не связанная со структурой строки таблицы.

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

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

Ты уточни о каких именно событиях говоришь, я тебе отвечу.

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

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

Я уже ответил, что конкретно в случае форума, сообщения надо не удалять, а помечать как удалённые. Удалённые сообщения на этом форуме не видны там, откуда их удалили, но видны при доступе по ID и в форуме Мусорка. Задача вообще какая-то искуственная.

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


A>>Влад, если нечего сказать по существу, то лучше вообще не писать,
VD>О, мудрая мысль. Но тебе придется сломать обе раку чтобы избежать искушения ответить мне .
VD>Вот этот ответ, например, не имеет никакого отношения к вопросу (да вообще ни к чему).
VD>Мой тебе совет. Прежде чем советовать окружающим о том про что им писать, или высказывать им свое мнение о том, что их слова не обоснованны, тебе лично нужно научиться обосновывать свои слова и смотреть на них критически.
A>>ведь разговаривать про клиентский кеш ты недавно отказался.
VD>И что? Он не имеет отношения к делу. В теме речь шла о доступе к данным (БД).

Клиентский кеш имеет к делу то простое отношение, что ты не смог со своим мегаметодом решить простейшую практическую задачу и тупо слил, прикрываясь оффтопиком.

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

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

G>>>>У вас проверки RLS не в коде?
A>>>Да, они в хранимках.
G>>От того что часть логики помещена в хранимки она логикой быть не перестает.
G>>Зато теперь понятно почему тебе так не нравятся запросы, используя хранимки для CRUD использование запросов становится неудобным и почти ненужным.

A>Ещё раз. проверка доступа это не логика, это инфрастурктурный сервис. Логика приложения может выражаться в раздаче прав доступа, проверка — операция универсальная, никак не связанная со структурой строки таблицы.

Инфраструктурный сервис логикой не является?
Ведь его приходится самому писать, этот сервис БД не дает забесплатно.

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

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

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

A>Я уже ответил, что конкретно в случае форума, сообщения надо не удалять, а помечать как удалённые. Удалённые сообщения на этом форуме не видны там, откуда их удалили, но видны при доступе по ID и в форуме Мусорка. Задача вообще какая-то искуственная.

Задача очень даже естественная, если кто-то зайдет и запостит педофильское порно, то такой пост сразу вытрут без всяки "мусорок".
Мусорка в данном случае — искуственный костыль непонятно для чего.

Далеко не всегда возможно забороть несогласованность данных, попытки делать это приводит к распухнию решения (в такой задаче уже появилась "мусорка" и флаг удаления).

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

G>Инфраструктурный сервис логикой не является?
G>Ведь его приходится самому писать, этот сервис БД не дает забесплатно.

Понимаешь, в протоколе HTTP тоже есть какая-то логика, но мы ведь не называем веб-сервис бизнес-логикой. Да, самому писать не приходится, я же БД генерирую, ты забыл

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

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

Зачем? Можно сделать спец-форум в который ни у кого не будет доступа.

G>Мусорка в данном случае — искуственный костыль непонятно для чего.

Мусорка это очень правильное решение. Из БД нельзя данные стирать.

G>Угу, попытался найти ссылки про принципы SOA, которые еще называют Soa triangle, но половина у меня не открылась, а вторая половина показала маркетологический булшит.
А что там за принципы могут быть кроме явной границы сервисов?

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

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

Молодец. А могло бы получится даже лучше.

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

G>>Угу, попытался найти ссылки про принципы SOA, которые еще называют Soa triangle, но половина у меня не открылась, а вторая половина показала маркетологический булшит.
Tom>А что там за принципы могут быть кроме явной границы сервисов?

Там много булшита. Люди же за это дело премии получали.

В принципе, конечно не плохо, что даже самые простые принципы оформлены формально. Плохо, что из этого пытаются создать религию.

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

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

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

A>Я уже ответил, что конкретно в случае форума, сообщения надо не удалять, а помечать как удалённые. Удалённые сообщения на этом форуме не видны там, откуда их удалили, но видны при доступе по ID и в форуме Мусорка. Задача вообще какая-то искуственная.

Да фиг с ними, с темами форума. Что произойдет (на каждом из слоев приложения), если пользователь в качестве ID пришлет что-нибудь типа

?ID='||'6

?

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

Tom>Можем перейти к примерам (оставим розового слоника в покое ).

Что это тебя вдруг от слоника или розового цвета начало колбасить?

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

Логика, даже бизнес, и что давай теперь сюда ещё и императив притащим, раз пошла такая пьянка? Ты пойми простую вещь, DAL, BL и прочие слои придумали не просто так. Они реально помогают жить, но только при одном условии — если это вполне осознаваемые сущности со строго очерченными функциями, а не только названия классов и умный вид перед начальством и коллегами, а в голове всё равно каша (как у Ромы).