для руководства (хотя уже кое-где используется). Я для себя решил в открытую такие аргументы привести:

1. Локализация слоев:
1.1. Доступа к данным (этот слой реализован непосредственно NHibernate). Что дает – все уже реализовано, сокращение времени на разработку и тестирование.
1.2. Бизнес-логики:
1.2.1. Обязательность определения классов предметной области:
1.2.1.1. Соответствие концепций/объектов/т.п. предметной области их программным эквивалентам. Что дает – тезаурус системы (с переводом на английский язык) сохраняется при программной реализации, минимум комментирования
1.2.1.2. Общий стиль мышления членов команды (не «вызовем хранимую процедуру для того-то и того-то … и того-то» (много), а «сохраним состояние объекта» (едино). Что дает – общение в едином технологическо-предметном контексте.
2. Легкое включение в проект новых участников (см. 1.2.1.1 и 1.2.1.2).
3. Четкое понимание членами проекта (см. 1.2.1.1), что нужно в первую очередь из документации разработать/актуализировать.

что скажете? может не на то делаю акцент?

Алексей КОбоснование логики в хранимых процедурах:

1. Локализация слоев:
1.1. Доступа к данным (работаем непосредственно в контексте БД). Что дает – все уже реализовано, сокращение времени на разработку и тестирование.
1.2. Бизнес-логики:
1.2.1. Обязательность определения представлений, описывающих сущности предметной области:
1.2.1.1. Соответствие концепций/объектов/т.п. предметной области их программным эквивалентам. Что дает – тезаурус системы (с переводом на английский язык) сохраняется при программной реализации, минимум комментирования
1.2.1.2. Общий стиль мышления членов команды (не абстрактно «сохраним состояние объекта», а «вызовем хранимую процедуру для того-то и того-то … и того-то», что дает – общение в едином технологическо-предметном контексте и понимание всеми участниками сути происходящего.
2. Легкое включение в проект новых участников (см. 1.2.1.1 и 1.2.1.2).
3. Четкое понимание членами проекта (см. 1.2.1.1), что нужно в первую очередь из документации разработать/актуализировать.

Что скажете? Может не на то делаю акцент?

ответ в виде стеба, я его пропустил. но тут посмотрел - вы вроде в недавном сраче эту позицию "Обоснование логики в хранимых процедурах" не обостряли - все же как-то с ОРМ. Нет?

То есть это в принципе холиварная тема, или все же есть объективные критерии, исследования, что-ли?

Для себя я пока решил 90% ("светлая бизнеслогика") ОРМ + остальное SQL ("темная бизнеслогика", когда не ясно что, как, и как оно может измениться)