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

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

3)Если надо переопределить логику CRUD, например пометка IsDeleted вместо удаления, то создавайте в СУБД вьюхи + instead of триггеры.
MB>>со вьюхами понятно — отображаем там тех кто у котрых IsDeleted=false. а вот с тригерами не совсем ... во первых тригеров не люблю — считаю их парашутом если при проектировании не учли то в тригирах отыграемся ну а если серьезно, то если заранее изветсна логика то лучше ее сразу вынести в рамки процесса а не в тригера... по этому если не против уточните.
G>Триггеры на вьюхе позволяют работать с ней как с таблицей. При переходе на вьюхи с триггерами код приложения менять не придется.

да, это достоинство в том случае если есть код и мень его ооооочень бы не хотелось. именно по этому я хочу оставить этот механизм на момент сопровождения приложения а не на стадии проектирования использовать последние рубежи. приложение пишется с нуля, будет большим — энтерпраз левел, весь код под контролем и пишется с нуля. по этому этот мезанизм я опишу как механизм которым можно будет воспользоваться, при необходимости, при сопровождении приложения... и то ...

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

G>>>Например в случае пометки удаленных записей флагом IsDeleted достаточно будет созать вьюху и написать один триггер на удаление, если делать с помощью процедур, то надо писать все 4 штуки.

да, сейчас используется CRUD без сикввела. т.е. весь код под контролем. все модули которые связаны с манипуляциями над бизнес сущностями не имеет возможности работать с базой напрямую — никакого контектса они не получают, по этому чтоб хотели то не получиться, а внутри "ServiceLayer", как правило объектов создавать или удалять нет необходимости, и на всякий случай, те кто имеют доступ до контекста строго проинструктированы, что в случае использования контекста для создания или удаления не по средствам интерфейса а напрямую через контекст — будут растреляны, реанимированы и потом еще раз растреляны, но уже в особо извращенной форме ну это лириука конечно, а всерьез, то если код под контролем и извне ServiceLayer можно проводить операции только по средствам итерфейса, по этому все подконтролем, и если нужно удалить то какая мне разница что я в операции делете сделаю вместо удаления установлю статус удаленная, или удалю а в тригире и перехвачу это и уже там поменяю статус.

причем удаление это не просто удаление как таковое, еще необходимо из кеша изьять у меня там Velocity вертиться, и что самое главное будет вызываться бизнес процесс на удалениие. т.е. некоторые объектов нужно просто удалить, а для удаления других нужно запросы на подтвореждение... т.е. там должен быть длинные бизнес транзаукции.

я кстати думаю не переутежеляю ли я CRUD. но посмотрим... но все равно нужно будет делать процесс удаления и само удаления это "разные" вещи...

G>>>4)Если вам нужна очень сложная логика CRUD, то создавайте хранимки
MB>>а почему очень сложная логика CRUD процедур, то в хранимки? не понятно очень сложную логику легче реализовать как раз не стороне шарпа ... поясните плиз для тех кто в танке
G>Я имею ввиду именно логику связанную с операциями CRUD. Например для выборки требуется танцы с курсорами, а вставка осуществляется каким-нибудь хитрым образом. Такие операции лучше делать хранимками. Но такие случаи встречаются очень редко.

G>Вся бизнес-логика должна быть в коде приложения, а не в БД.

есть какие-то против ? может я не заметил подводных течений ?