можно не делать сложных ХП. Сложную ХП можно представить в виде простых сервисов. Просто для этого кардинально другие подходы нужно применять при проектировании приложений. То, к чему привыкли при разработке настольных КС систем конечно воспринимается чем-то непомерно сложным.

ДжекНепотрошительiscrafmможно не делать сложных ХП. Сложную ХП можно представить в виде простых сервисов. Просто для этого кардинально другие подходы нужно применять при проектировании приложений. То, к чему привыкли при разработке настольных КС систем конечно воспринимается чем-то непомерно сложным.

Я скажу, что с точки зрения сопровождение бизнес-логики на ХП, не сильно принципиально, как выглядит сложный алгоритм - в виде одной большой процедуры, разбитой на функциональные блоки и с комментариями, или в виде нескольких маленьких. Все равно тяжелее сопровождать, нежели аналогичный алгоритм на каком-нибудь объектно-ориентированненьком ЯВУ. Здесь играет роль не столько оформление кода, сколько выразительность самих средств ЯВУ по сравнению со всякими там T-SQL, средства навигации и отладки и тому подобные фишки.
я скажу, что SOA систему на порядок легче сопровождать, чем то, что Вы сказали.

ДжекНепотрошительЗдесь играет роль не столько оформление кода, сколько выразительность самих средств ЯВУ по сравнению со всякими там T-SQL
речь идет об элементарном атомарном действии. Озвученная Вами выразительность нужна в том случае, если есть что выражать. Именно чтобы не утонуть в дебрях ООП кода и нужны все эти средства. Если система построена в SOA архитектуре, то выразительное представление маленького "черного ящика" просто не играет какой-либо значимой роли

ДжекНепотрошительiscrafmя скажу, что SOA систему на порядок легче сопровождать, чем то, что Вы сказали.
Я напомню, что мы говорим не про SOA, а про бизнес-логику на ХП. Вы сейчас утверждаете, что теплое лучше мягкого. Ведь SOA - это вариант взаимодействия модулей приложения, ХП - вариант реализации конкретных модулей. Вы можете сделать SOA с ХП, а можете сделать SOA на ЯВУ. Второе сопровождать легче, чем первое :)
бизнес-логику можно спроектировать и реализовать различными способами. Я утверждаю, что те же ХП в архитектуре о которой я говорю выглядят совершенно не так, как Вы их здесь представляете, т.е. нет тех алгоритмических сложностей, которые требуют, в свою очередь, сложных инструментов для их поддержки. Сложности перемещаются с уровня кодирования на уровень проектирования. Процедуры выглядят очень примитивно, потому что они действительно выполняют строго ограниченные функции, а компоновка бизнес-логики - уровнем выше. Как формулы в Excel, при размещении которых в ячейках в определенной последовательности можно реализовать бизнес-логику, которая альтернативно реализуется при помощи VBA.

ДжекНепотрошительiscrafm Я утверждаю, что те же ХП в архитектуре о которой я говорю выглядят совершенно не так, как Вы их здесь представляете, т.е. нет тех алгоритмических сложностей, которые требуют, в свою очередь, сложных инструментов для их поддержки. Сложности перемещаются с уровня кодирования на уровень проектирования. Процедуры выглядят очень примитивно, потому что они действительно выполняют строго ограниченные функции, а компоновка бизнес-логики - уровнем выше. Как формулы в Excel, при размещении которых в ячейках в определенной последовательности можно реализовать бизнес-логику, которая альтернативно реализуется при помощи VBA.
Т.е. речь идет о том, что у вас нет бизнес-логики, реализованной на ХП, а хранимки выполняют роль интерфейса доступа к данным, верно?
Взять тот же расчет ЗП, упомянутый в этой ветке N сообщений тому назад. Вы можете написать какой-нибудь сервис "Payroll", который будет иметь методы "сформировать ведомость начислений по сотруднику/подразделению за указанный период", "получить ведомость", "закрыть ведомость". А можете написать сервисы "Timetable", "Employees", "Calendar" и т.д., которые являются безмозглыми прокси к данным, и самое сложное в логике их работы - проверка прав доступа. Но в этом случае у вас бизнес-логика все-таки на чем-то высокоуровневом написана, так ведь?
не совсем понятно что означает "у вас". Я не говорю конкретно по какую-то свою систему, я говорю про сам подход. Если говорить о поднятом вами примере, то сервисом будет не "Payroll", а будут сервисы:
- "сформировать ведомость начислений по сотруднику/подразделению за указанный период"
- "получить ведомость"
- "закрыть ведомость"
- и т.д
задача архитектора, во-первых, выделить эти сервисы, а во-вторых, скомпоновать их для реализации какой-то бизнес-логики. Т.е. это не методы объекта (ключевое), это функции и процедуры, если уж проводить аналогии с программированием, которые могут выполняться как обособленно (основа SOA - все сервисы независимы друг от друга), так и в комплексе (основа SOA - система компонуется из сервисов, которые являются слабосвязанными компонентами).
На чем-то высокоуровневом бизнес-логика не пишется. На высокоуровневом пишется сервисная шина, интервейсы их регистрации, взаимодействия и т.д. Но это все совершенно одинаковые интерфейсы что для бухгалтерии, что для системы планирования, что для документооборота и т.д.