Здравствуйте, VGn, Вы писали:
VGn>Как-то даже сложно с аналогами. Потому что как раз о корпоративных приложениях я там ничего не нашёл. VGn>Трудно назвать корпоративным приложение, в котором смешиваются воедино уровень доступа к данным, Domain уровень, уровень сервисной бизнес-логики и ещё всего помаленьку.
У вас какой-то неправильный Фаулер. У моего такого смешения не наблюдается.
VGn>А для ваших настольных систем — это вполне себе как раз. Только Enterprise тут ни при чём.
Ваш ход сударь. Какие подходы рулять в тру-Enterprise приложениях?
Пожалуйста с сылочками на что-то большее чем блог Ивана Ивановича Иванова.
T>Нет, ты не предлагаешь сократить передечу в базу. В твоем сценарии данные сначала пишутся в базу, а потом валидируются. То есть даже невалидные данные ты передаешь. И где тут сокращение?
Всё зависит от логики валидации.
Если валидируется формат, то это можно сделать и на уровне отображения.
Если логическая нестыковка — то в бизнес-логике.
Если конфликт с существующими данными или конфликт транзакций, то только на базе.
Причём имхо это всё не жёсткие условия. Всё зависит от архитектуры системы.
Здравствуйте, VGn, Вы писали:
VGn>Всё зависит от логики валидации. VGn>Если валидируется формат, то это можно сделать и на уровне отображения. VGn>Если логическая нестыковка — то в бизнес-логике. VGn>Если конфликт с существующими данными или конфликт транзакций, то только на базе. VGn>Причём имхо это всё не жёсткие условия. Всё зависит от архитектуры системы.
Вопрос был не к тебе. По его словам проверка объектов должна быть в двух местах — PL + база.
Я как раз пытаюсь вытянуть его на то, что проверки в бизнесе все-таки нужны.
T>У вас какой-то неправильный Фаулер. У моего такого смешения не наблюдается.
Я делал вывод по примерам кода в книге. К сожалению читал это очень давно и специально для вас рыть больше не охота.
VGn>>А для ваших настольных систем — это вполне себе как раз. Только Enterprise тут ни при чём.
T>Ваш ход сударь. Какие подходы рулять в тру-Enterprise приложениях?
Обычные подходы. Многозвенность. Многослойность. Может быть больший упор на сервисы.
Долгоживущие объекты не приветствуются. Запросы возвращают минимально-необходимые наборы данных. Избыточность функциональности не приветствуется. Модульность и расширяемость — наше всё.
В общем всё также, только строже и с упором на масштабируемость.
T>Пожалуйста с сылочками на что-то большее чем блог Ивана Ивановича Иванова.
Здравствуйте, VGn, Вы писали:
T>>У вас какой-то неправильный Фаулер. У моего такого смешения не наблюдается. VGn>Я делал вывод по примерам кода в книге.
Зря, если бы читали, то таких выводов бы не делали.
VGn>К сожалению читал это очень давно и специально для вас рыть больше не охота.
Почему-то не удивлен.
VGn>>>А для ваших настольных систем — это вполне себе как раз. Только Enterprise тут ни при чём.
T>>Ваш ход сударь. Какие подходы рулять в тру-Enterprise приложениях?
VGn>Обычные подходы. Многозвенность. Многослойность. Может быть больший упор на сервисы. VGn>Долгоживущие объекты не приветствуются. Запросы возвращают минимально-необходимые наборы данных. Избыточность функциональности не приветствуется. Модульность и расширяемость — наше всё.
В общем-то никаких принципиальных отличий от Фаулера при первом просмотре и нет.
VGn>В общем всё также, только строже и с упором на масштабируемость.
T>>Пожалуйста с сылочками на что-то большее чем блог Ивана Ивановича Иванова.
VGn>Не получится. Обычно такие вещи конфиденциальны.
T>>>У вас какой-то неправильный Фаулер. У моего такого смешения не наблюдается. VGn>>Я делал вывод по примерам кода в книге. T>Зря, если бы читали, то таких выводов бы не делали.
Читал. Просто примеры вызвали более явное отторжение.
VGn>>В общем всё также, только строже и с упором на масштабируемость. T>>>Пожалуйста с сылочками на что-то большее чем блог Ивана Ивановича Иванова. VGn>>Не получится. Обычно такие вещи конфиденциальны. T>
По вопросу примеров корпоративного кода это практически стандартный ответ на форуме.
Да и смотреть там в общем и нечего: архитектуру по коду не понять, тем более что на уровне кода абсолютно все достаточно здоровые корпоративные системы, которые я видел, написаны через жопу (конечно я не имею в виду свой собственный код и код своей команды )
Здравствуйте, Tissot, Вы писали:
T>Потому что update
Если это один update, то там не может быть никаких длинных вычислений.
T>Не надо менять условия задачи, чтобы подогнать желаемый результат.
А ты чем занимаешься? Просто в эту игру можно играть в обе стороны
T>Я не знал, что если в батче содержится несколько стейтментов, то сервер анализирует весь батч целиком. Всегда был уверен, что он выполняет стейтмент за стейтментом.
Выполняет, конечно последовательно, но информации ему хватает, за подробностями к учебникам по СУБД.
T>Ключевое слово выделено. А на практике?
А на практике этого еще не сделано, о чем и писал Влад.
T>А как еще назвать ситуацию, когда в качестве аргумента приводят код, который в жизни практически не встречается?
Задача стояла не показать тебе реальный код, а проиллюстрировать идею.
T>Приведенный код был слишком простым, чтобы на его примере увидить недостатки подхода "делаем все одним update-ом". Де-факто этот единственный update потребует как минимум проверку валидности, проверку безопасности, аудит действий и т.д. Если бы все эти сервисные операции были включены в пример, то его красота сразу бы куда-то улетучилась.
В том-то и дело, что не улетучилась бы, если использовать подход LINQ, в чем и был поинт оригинального сообщения.
T>Очень интересный тезис, но позволь в него не поверить.
Да байта ради.
T> Ну или по-крайней мере объясни откуда возьмется этот больший контроль.
Оттуда, что все делается явно, без Lazy Loading-ов, неявных кешей, траверсивных запросов и прочих ритуальных приседаний.
Здравствуйте, Tissot, Вы писали:
T>Я довольно регулярно слежу за тенденциями в этой сфере. И мне как-то последние годов несколько очень редко попадаются апологеты подхода "запихнем все в базу". Все больше как-то говорят за полноценную domain model.
"запихнем все в базу" и domain model — это ортогональные вещи, так что довольно странно слышать подобные заявления от человека, который "регулярно следит за тенденциями в этой сфере".
T>Стандартность означает распространенность, распространенность означает что большинство граблей уже найдено и найдены способы как с ними бороться.
Да-да, мыши плакали, кололись, но продолжали жрать кактус.
T>В сухом остатке получаем, что подход с domain model более "проработан" чем иные. T>Это тоже будешь считать более хлипким аргументом?
Безусловно, так как народ уже начинает понимать, какой это фуфел. Апофигеем того, что ты понимаешь под domain model был EJB, который, пользуясь твоим любимым аргументом, де-факто, считается провальным.
T>Не мог бы ты оставаясь в рамках этого примера описать, откуда возникнет "меньшее время" и "больший контроль"?
Почему это я должен оставаться в рамках твоего примера, если ты не хочешь? В реальной жизни, никто не занимается длинными вычислениями между двумя update-ами, все тяжелые вещи делаются заранее или задача вообще решается иным способом.
T>Что тебя так развеселило? Расскажи, вместе посмеемся.
Дешевые понты всегдя выглядят забавно.. )
Здравствуйте, Tissot, Вы писали:
T>Меня несколько смутило, что insert-ы, да update-ы относят к реляционным операторам. Теперь ясно что имелось в виду другое. Проехали.
То есть, просто искал к чему бы придраться. ок, проехали.. =)
T>Раз уж мы аппелируем к большинству, то это большинство какраз-таки пользуется разными Hibernate-ами вовсю.
Во-первых H — это не OOBD, во-вторых, H можно использовать очень по разному ну и, наконец, в третих, "большинство" — это тоже сильное преувеличение.
T>Наследование. Отношения многие ко многим.
Это все отлично выражается в ER, стыдно не знасть.
T>Методы. Интерфейсы.
А это вообще никакого отношения к данным не имеет.
T>См. Фаулера. Перепечатывать цитаты я не буду.
Ты на фаулера не кивай, с ним уже разобрались. У тебя свои-то мысли есть?
T>Большое количество однородных объектов. В качества примера можно привести например миграцию данных с одной схемы базы на другую.
Тогда ты фигню сказал. UoW сливает везде, где обьектов больше одного.
Здравствуйте, Tissot, Вы писали:
T>Спасибо за развернутый и аргуметированный ответ.
Я стараюсь соответствовать оппоненту..
T>Вы раскрыли мне глаза.
Всегда пожалуйста, заходите еще..
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
T>>>Не мог бы ты оставаясь в рамках этого примера описать, откуда возникнет "меньшее время" и "больший контроль"?
G>>Если расчеты в п2 не зависят от апдейта в п1, то сначала выполняем расчеты (не ставим эксклюзивные блокировки), потом формируем 2 апдейта и выполняем их в БД. G>>Если расчеты в п2 зависят от апдейта в п1, то выделяем независимую часть расчетов из п2 и выполняем, потом выполняем апдейт, зависимую от апдейта часть расчетов (гораздо быстрее), мерджим с независимой, выполняем второй апдейт.
T>А можно не изменять условия задачи?
Никто не меняет условия, входные и выходные данные остаются. Вы почему-то пытаетесь доказать неправильность какого-то подхода через свое кривое решение. Если решение не кривое, то и подход оказывается вполне нормальным.
T>А то при таком подходе и я теорему Ферма на коленке за минут докажу.
Ну доказывайте.
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
T>>>Под ER-моделью я, как ни странно, понимаю ER-модель G>>Круто. А как это использовать в программе? T>Собственно ER модель мапится в объектную очень легко. Практически один в один.
Ну вот и я о томже. Обекты — форма, ER — суть. При маппинге ER на объекты у вас не появятся виртуальные методы и все такое, то есть не будет полновесного ООП.
G>>Вы вообще представляете то о чем спор ведете? T>Пока что я пытаюсь выяснить что вы имели в виду под ER-моделью. Пока что выяснилось, что ваша ER-модель != ER-модели как ее представлет википедия.
Да, я имею ввиду использование этой модели в программе.
T>>>Ясно. Я использовал такой подход в простых сценариях, когда при определенных условиях нужно было применять дополнительное условие. T>>>Но такой подход не всегда применим. В частности, в проекте на котором я сейчас работаю настройки безопасноти (привелегии) хранятся во внешней базе. G>>Ну это надуманные проблемы. Всегда есть view, linked servers и прочее. Только далеко не все могут нормальную интеграцию баз сдеать на уровне БД. Гораздо проще сделать в коде приложения, а потом рассказывать что это "непрстой сценарий" и прочее.
T>И как view и linked servers ты собрался вписать в LINQ-подход?
Никак, это все делается на уровне БД. А Linq2SQL\EF уже работает с таблицами и вьюхами в одной БД.
T>>>>>То есть каждому пользователю давать свой логин в базе? Ты в курсе, что так делать не рекомендуют? G>>>>Нет, есть таблица, хранящая логины и другие сведения о пользователях. В логах можно ссылкаться на эту таблицу.
T>>>А как определить текущего пользователя? G>>Разве вы в программе в кажом месте не можете определить текущего пользователя (логин\id\что_нибудь_еще)?
T>В программе — могу. А вот как это сделать это в триггере для меня не ясно. Если вы знаете, буду благодарен если просвятите.
Я бы с таком случае сделал в таблицах поля Owner и LastModifiedBy. Триггеры из них достанут нужную инфу.
T>>>Почему не понадибится? Как иначе проверишь, что определенные действия отражаются в аудит-логе? G>>Тесты базы будут запускаться при разработке БД. С тестированием кода приложения они не связаны. Пусть build-система на сервере гоняет такие тесты хоть каждые 5 минут, каждому разработчику делать тоже самое необязательно.
T>Э, нет, так не пойдет. Код не должен выкладываться в репозитарий если он не прошел тесты.
Если вы не делаете изменений в базе, то можете не перезапускать тесты БД. Ничего там сломаться не может.
T>>>БД — это всегда узкое место. Если есть возможность делать проверки в бизнесе, они болжны быть сделаны в бизнесе. Неужели эти банальности нужно повторять? G>>Эти "банальности" еще нужно доказать. G>>Сама по себе БД — не узкое место, узкое мето — передача данных от БД к приложению и назад. Именно эту передачу и предлагают сократить.
T>Нет, ты не предлагаешь сократить передечу в базу. В твоем сценарии данные сначала пишутся в базу, а потом валидируются. То есть даже невалидные данные ты передаешь. И где тут сокращение?
Сокращения в том что данные из базы вообще не тянутся в приложение.
G>>Содержание бизнес-логики в коде приложения выгодно не с точки зрения перформанса, а с точки зрения стоимости поддрежки. Но при работе с запросами логика остается в коде приложения, меняется только место исполнения. G>>БД кстати очень хорошо умеет параллелить выполнение запросов, использует индексы, чтобы даже не забивать память данными, не используемыми в запросах, умеет кешировать часто используемые данные и гораздо лучше управляет блокировками и конкуретным доступом, чем любая реализация в коде приложения.
T>А где я предлагал кэшировать/управлять блокировками/управлять конкурентным доступом в приложении?
А вы UoW не предлагали? В нем часто заключается и кеширование, и управление блокировками.
G>>>>Это так и есть. T>>>И как это сочетается с тем, что валидацию ты возлагаешь на базу, когда ее можно сделать в бизнесе, что дешевле? G>>Что значит "дешевле"? T>Быстрее, будет потреблять меньше ресурсов,
Именно все делать в базе окажется дешевле.
G>>При правильном подходе возлагать работу с данными на БД даст огромный прирос производительности. T>Не надо растекаться мыслью по древу. Как в предложенном тобой сценарии использования валидации в базе получится большая производительность?
Так и получится.
G>>Сравните например например выполнение запроса типа "увеличить скидку всем VIP кастомерам скиду на все заказы прошлого года на 3 процента" с выполнением тогоже самого с помощью ORM. T>Про массовые update-ы я писал. Тут все ясно, согласен на все 100.
Даже в случае одного такого апдейта простой запрос выполнится быстрее.
T>Спасибо, почитаю. T>Читал предыдущую версию. Неужели что-то коренным образом изменилось?
Там изначально меньша каши чем у фаулера.
Здравствуйте, Tissot, Вы писали:
T>А я и не хамлю. T>Пункт 4 не выполнен.
Я намеренно не стал приводить полный код. Пункт четыре достигается одной дополнительной строчкой. В реальной жизни, конечно же, бизнес-транзакция не сведется к одному update. Она сведется к небольшому количеству update, которые выполняются без передачи лишней информации за пределы СУБД.
T>Кстати, еще одно вспомнилось, что непонятно как поддеживать в Linq-е — рекурсивные запросы.
Есть много способов поддерживать рекурсивные запросы. Худший из них — выполнение рекурсии вне СУБД.
T>Дерзайте, я не против.
Это хорошо. Мне как раз показалось, что ты против.
T>Если что получится — хорошо, значит примем на вооружение еще один прием. T>Не получится — тоже хорошо, значит я был прав.
T>Опять нифига не понятно. Чтение в Unit of Work в конечном итоге — это тот же SELECT. Тут или ты чего не договоариваешь, или .. на этом моя мысль заканчивается.
В Unit of Work чтение — это обращение к объектам. Причем выполняется оно в две фазы:
1. Подъем объектов в память (в этот момент работает select)
2. Обращение к свойствам объектов.
Как правило, операция №1 настолько дорога, что ее выполняют через кэш. Кэширование на корню убивает возможность автоматической блокировки прочитанных объектов. Поэтому для обеспечения целостности приходится делать дополнительные приседания. Например, вручную блокировать интересующие объекты.
Конечно, можно обойтись и без кэша. Но тогда ситуация будет достаточно малоприятной для unit of work из-за просада производительности.
Теоретически, можно было бы трассировать и операции №2, аналогично тому, как это делается для отслеживания модификаций. Но на практике я такого не встречал. Смею полагать, что тоже по соображениям производительности.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, IB, Вы писали:
T>>Я довольно регулярно слежу за тенденциями в этой сфере. И мне как-то последние годов несколько очень редко попадаются апологеты подхода "запихнем все в базу". Все больше как-то говорят за полноценную domain model. IB>"запихнем все в базу" и domain model — это ортогональные вещи, так что довольно странно слышать подобные заявления от человека, который "регулярно следит за тенденциями в этой сфере".
Да ну? Как это они могут выть ортогональными, если вопрос по сути является вопросом о том, куда помещать бизнес-логику. Тут уж либо он в базах/запросах, либо в domain model.
T>>Стандартность означает распространенность, распространенность означает что большинство граблей уже найдено и найдены способы как с ними бороться. IB>Да-да, мыши плакали, кололись, но продолжали жрать кактус.
А в это время другие мыши пробуют все вокруг, не подозревая даже о том, что кто-то им от души подсыпал крысиного яда. Удачи.
T>>В сухом остатке получаем, что подход с domain model более "проработан" чем иные. T>>Это тоже будешь считать более хлипким аргументом? IB>Безусловно, так как народ уже начинает понимать, какой это фуфел.
Мне не уловить ход твоих мыслей. Как из проработанности следует что это является фуфелом?
IB>Апофигеем того, что ты понимаешь под domain model был EJB, который, пользуясь твоим любимым аргументом, де-факто, считается провальным.
Не, EJB был оверкилом, он как раз сильно ограничивал возможности использования ООП.
T>>Не мог бы ты оставаясь в рамках этого примера описать, откуда возникнет "меньшее время" и "больший контроль"? IB>Почему это я должен оставаться в рамках твоего примера, если ты не хочешь? В реальной жизни, никто не занимается длинными вычислениями между двумя update-ами, все тяжелые вещи делаются заранее или задача вообще решается иным способом.
В реальной жизни ты разбиваешь задачи на долее мелкие и дашь их разным людям и не факт, что исполнитель второй задачи будет знать, что те данные, которые он меняет, были изменены чуть выше по коду первым исполнителем.
T>>Что тебя так развеселило? Расскажи, вместе посмеемся. IB>Дешевые понты всегдя выглядят забавно.. )
Я правильно тебя понимаю, что ты не считаешь упомянутую мною Axapta крупным приложением? А что по твоему мнению ты относишь к числу таковых?
Здравствуйте, Sinclair, Вы писали:
T>>Кстати, еще одно вспомнилось, что непонятно как поддеживать в Linq-е — рекурсивные запросы. S>Есть много способов поддерживать рекурсивные запросы. Худший из них — выполнение рекурсии вне СУБД.
Конструктивнее. Давай лучшие в студию.
T>>Опять нифига не понятно. Чтение в Unit of Work в конечном итоге — это тот же SELECT. Тут или ты чего не договоариваешь, или .. на этом моя мысль заканчивается. S>В Unit of Work чтение — это обращение к объектам. Причем выполняется оно в две фазы: S>1. Подъем объектов в память (в этот момент работает select) S>2. Обращение к свойствам объектов. S>Как правило, операция №1 настолько дорога, что ее выполняют через кэш. Кэширование на корню убивает возможность автоматической блокировки прочитанных объектов. Поэтому для обеспечения целостности приходится делать дополнительные приседания. Например, вручную блокировать интересующие объекты.
Кэш — в топку.
S>Конечно, можно обойтись и без кэша. Но тогда ситуация будет достаточно малоприятной для unit of work из-за просада производительности.
Отлично. Осталось выяснить откуда взялся просад производительности.
Что такого сложного в том, чтобы сделать select и результат распихать по свойствам?
Здравствуйте, IB, Вы писали:
T>>Потому что update IB>Если это один update, то там не может быть никаких длинных вычислений.
update не один. смотри выше постановку задачи.
T>>Не надо менять условия задачи, чтобы подогнать желаемый результат. IB>А ты чем занимаешься? Просто в эту игру можно играть в обе стороны
Я не меняю условия задачи. Вариант, когда в одной бизнес-операции выполняются несколько update-ов одной сущности считаю вполне жизненным.
T>>Я не знал, что если в батче содержится несколько стейтментов, то сервер анализирует весь батч целиком. Всегда был уверен, что он выполняет стейтмент за стейтментом. IB>Выполняет, конечно последовательно, но информации ему хватает, за подробностями к учебникам по СУБД.
Не, так легко ты не отделаешься. Учебников мною прочитано предостаточно, но информации о том, чтобы СУБД отпускала блокировки до окончания танзакции, я слышу в первый раз.
T>>Ключевое слово выделено. А на практике? IB>А на практике этого еще не сделано, о чем и писал Влад.
ok
T>>А как еще назвать ситуацию, когда в качестве аргумента приводят код, который в жизни практически не встречается? IB>Задача стояла не показать тебе реальный код, а проиллюстрировать идею.
Ну идея сама по себе была ясна и из первого поста
T>>Приведенный код был слишком простым, чтобы на его примере увидить недостатки подхода "делаем все одним update-ом". Де-факто этот единственный update потребует как минимум проверку валидности, проверку безопасности, аудит действий и т.д. Если бы все эти сервисные операции были включены в пример, то его красота сразу бы куда-то улетучилась. IB>В том-то и дело, что не улетучилась бы, если использовать подход LINQ, в чем и был поинт оригинального сообщения.
Делайте, посмотрим. Если на добавление LINQ-а у разработчиков Nemerle ушло (по их заявлениям) совсем не много времени, то добавить insert-ы с update-ами будет не намного сложнее.
T>> Ну или по-крайней мере объясни откуда возьмется этот больший контроль. IB>Оттуда, что все делается явно, без Lazy Loading-ов,
Используйте ef
IB>неявных кешей,
Кэш неявный только когда ты о нем не знаешь. Изучайте получше инструмент, которым пользуетесь.
IB>траверсивных запросов и прочих ритуальных приседаний.
Здравствуйте, gandjustas, Вы писали:
G>>>Если расчеты в п2 не зависят от апдейта в п1, то сначала выполняем расчеты (не ставим эксклюзивные блокировки), потом формируем 2 апдейта и выполняем их в БД. G>>>Если расчеты в п2 зависят от апдейта в п1, то выделяем независимую часть расчетов из п2 и выполняем, потом выполняем апдейт, зависимую от апдейта часть расчетов (гораздо быстрее), мерджим с независимой, выполняем второй апдейт.
T>>А можно не изменять условия задачи? G>Никто не меняет условия, входные и выходные данные остаются. Вы почему-то пытаетесь доказать неправильность какого-то подхода через свое кривое решение. Если решение не кривое, то и подход оказывается вполне нормальным.
Это решение не кривое, а вполне себе жизненное. В сколь-нибудь крупном приложении никогда не бывает такого, что все связи видны и прозрачны.
Сегодня у тебя была какая-то одна задача, которую ты вполне успешно разбил на независимые (в том числе по данным) подзадачи и успешно решил, через полгода тебе или твоему коллеге приходит minor change request, в которым просят изменить что-то в логике первоначальной задачи. Это изменение будут затрагивать одну из подзадач первоначальной задачи. Но получится так, что в результате подзадачи перестанут быть независимыми по данным. У тебя будет два выхода, либо все отрефакторить во имя "правильного" подхода, либо внести изменения по месту и смириться с тем, что независимость по данным потеряна. Первый вариант гарантированно займет больше времени. Ваши действия, сударь?
Мне даже пример пришел в голову, все с тем же резервированием по накладной.
Первоначальная постановка:
По нажатию на кнопочку "Резерв." в форме заказа зарезервировать остатки на складе и послать во внешнюю систему (веб-сервис) запрос на упаковку.
Решение: задача разбивается на 2 более мелких: 1) изменить остатки 2) послать запрос на упаковку.
CR (через полгода):
При резервировании заказа заказ должен сохранять в одном из полей номер запроса на упаковку (номер возвращается веб-сервисом).
Здравствуйте, gandjustas, Вы писали:
G>>>Ну это надуманные проблемы. Всегда есть view, linked servers и прочее. Только далеко не все могут нормальную интеграцию баз сдеать на уровне БД. Гораздо проще сделать в коде приложения, а потом рассказывать что это "непрстой сценарий" и прочее.
T>>И как view и linked servers ты собрался вписать в LINQ-подход? G>Никак, это все делается на уровне БД. А Linq2SQL\EF уже работает с таблицами и вьюхами в одной БД.
Деталей, побольше деталей.
Я так понимаю, ты предлагаешь насоздавать в основной базе кучу вьюх, которые будут которые фактически будут таблицами в другой базе (security)? После этого, ты переносишь эти вьюхи в LINQ2SQL дизайнер и работаешь с ними стандартными способами, которые предоставляет LINQ? Я правильно тебя понял? Ничего не упустил?
Если это так, то имхо, это просто ужасный вариант.
Если предполагается использовать security базу в более чем одной подсистеме, то: такой подход порождает дублирование всех security-таблиц. Эти типы будут несовместимы меж собой. Нельзя будет написать для этих типов общий код. При внесении изменений в security-подсистему, эти изменения нужно будет нетривиальным способом переносить во все места, где она используется.
G>>>Разве вы в программе в кажом месте не можете определить текущего пользователя (логин\id\что_нибудь_еще)?
T>>В программе — могу. А вот как это сделать это в триггере для меня не ясно. Если вы знаете, буду благодарен если просвятите. G>Я бы с таком случае сделал в таблицах поля Owner и LastModifiedBy. Триггеры из них достанут нужную инфу.
Эти поля тебе придется не забывать прописывать при всех изменениях. А если речь идет об удалении, то и вовсе — сначала обновить поле LastModifiedBy и только потом делать delete. В случае LINQ2SQL это вообще можно сделать прозрачно для польователя.
T>>Э, нет, так не пойдет. Код не должен выкладываться в репозитарий если он не прошел тесты. G>Если вы не делаете изменений в базе, то можете не перезапускать тесты БД. Ничего там сломаться не может.
Ответ неверный. Тесты должны запускаться всегда.
T>>Нет, ты не предлагаешь сократить передечу в базу. В твоем сценарии данные сначала пишутся в базу, а потом валидируются. То есть даже невалидные данные ты передаешь. И где тут сокращение? G>Сокращения в том что данные из базы вообще не тянутся в приложение.
Зато они пишутся в базу. И далеко не факт, что это дешевле.
G>>>БД кстати очень хорошо умеет параллелить выполнение запросов, использует индексы, чтобы даже не забивать память данными, не используемыми в запросах, умеет кешировать часто используемые данные и гораздо лучше управляет блокировками и конкуретным доступом, чем любая реализация в коде приложения.
T>>А где я предлагал кэшировать/управлять блокировками/управлять конкурентным доступом в приложении? G>А вы UoW не предлагали? В нем часто заключается и кеширование, и управление блокировками.
UoW не кэширует запросы, а только объекты, про управление блокировками вообще в первый раз слышу (или ты про optimistic locking?).
Что там насчет конкурентного доступа?
G>>>>>Это так и есть. T>>>>И как это сочетается с тем, что валидацию ты возлагаешь на базу, когда ее можно сделать в бизнесе, что дешевле? G>>>Что значит "дешевле"? T>>Быстрее, будет потреблять меньше ресурсов, G>Именно все делать в базе окажется дешевле.
Уверяю тебя, это далеко не вегда так. Проверить string.IsNullOrEmpty(customer.Name) да порядка три будет быстрее, чем запись customer.Name в базу.
(конечно я не имею в виду свой собственный код и код своей команды 
Мы уже победили, просто это еще не так заметно...
