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

NL>В идеале для реализации ООП подхода в полной мере нужно получить набор доменных обьектов с методами и все.
Почему существует таое мнение, что ООП = доменная модель, а отсутстие доменной модели это не ООП.

Вся разница заключается в том, какой вариант выбрать:

order.Process()

или

orderProcessor.Process(order)

При этом ВСЕДА внтури первого варианта вызывается второй.

NL>Т.е. бизнес логика должна быть выражена на чистом языке программирования без примесей технических деталий.
Меня всегда умиляла наивность подобных утверждений.
Вот есть простое правило — нельзя продать два билета на одно место. Мы делаем систему для продажи билетов в театр в кассах по всему городу.

На каком языке это правило выразить проще всего? Внезапно SQL. То же самое правило, записанное на C#, займет гораздо больше строк и гораздо больше технческих деталей будет содержать.


NL>Бизнес правила и так слишком сложны. Код больше читают, чем пишут.
Многие "правила" являются не инвариантами, а пред- или пост- условиями для опредеенных тразакций. В сложных случаях доходит до того, что у разных транзакций предусловия будут противоречить друг другу и виде "бизнес-правил модели" их не запишешь. Поэтому чем сложнее система, тем лучше подойдет архитектура transaction script, безотносительно того какими средствами генерируются запросы к базе данных.