daly,

я наверно что-то не понимаю, но почему не переложить все более-менее сложные CRUID на хранимки? Валидацию также можно делать через перекомпиляцию хранимок.

Blazkowicz,

код, обрабатывающий данные в БД, должен быть поближе к этим данным (не моё). Согласны? Я, честно говоря, не вижу противопоказаний, если это не работа с одной табличкой. Может поясните про "очень толстыми процессами бизнес-логики"? Наверняка все это можно разделить на считывание/запись каких дискретных значений из каких-нить источников, и на обработку(CRUD и селекты) этих данных.

BlazkowiczДа, но бизнес-процессы они не "обрабатывают данные в БД". В объектах точно так же есть данные и поведение, как можно ближе к ним. Так что безосновательное утверждение.


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

BlazkowiczПоясню. Обычно Create/Update превращается в следующее.
- Сходить на FTP, стянуть CSV, сравнить с сохраняемым объектом
- Обновить Legacy базу данных деталями из новой системы (в той же транзакции с возможностью отката)
- Послать куда-нибудь SOAP запрос и сообщить об обновлении
- Сходить ещё в пару мест по неожиданным протоколам, чтобы считать\отправить данные.

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

Я не говорю, что это всё не реализуемо в PL/T-SQL. Но в Java поддержка всевозможных протоколов, распраделенных транзакций и ООП намного интереснее.

не вижу противоречия с моими словами, что можно разделить на считывание/запись из источников (FTP и т.д.), и обработку в БД. Повторюсь, для простых операций не стоит городить огород, спорить не буду.