Здравствуйте, Козьма Прутков, Вы писали:

КП>Класс. Но тут как раз и происходит та проблема, о которой я говорил: ты можешь перевести объект в неконсистентное состояние. То есть легко сунуть ему новую страну, а потом сразу в БД.

Сразу в бд неполучится, т.к. насколько я понимаю AddressService.AddAddress должен быть единтвенным доступным способом сохранить объект, а он делает валидацию.

Но проблему это все равно не решает, так как с объектом еще необходимо работать и программно (из бинзес логики). И когда я передаю такой объект, например, параметром в какую-нибудь функцию, то я хочу, чтобы он был в валидном состоянии. А проверять каждый раз — это лучше сразу застрелиться.
Поэтому лучше, чтобы объект был написан таким образом, чтобы не было возможности перевести его в невалидное состояние. Ведь именно для этого и придумана инкапсуляция и свойства с сеттерами, не так ли?

Таким образом получается, что для работы с формами лучше иметь бизнес объекты с:

— наличием конструктора с определенной сигнатурой, например, конструктора без параметров, чтобы форма (или другой сервис) могла без проблем создавать новые объекты
— полями (без сеттеров), чтобы форма могла присваивать значения в любой последовательности
— и функцией validate, которая вызывается формой или другими сервисами автоматически.

А для программной работы лучше иметь визнес объекты, написанные по всем правилам ООП:

— с такими конструкторами, какие необходимы логически
— со свойствами
— и т.д.

Получается противочечие .

Я вот пишу движок для всего этого (времени много, начальство одобряет). Есть свой язык, своя VM. И если представить, что можно реализовать любые экзотические конструкции в языке, специально для объявления и работы с бизнес объектами, какие-бы вы предпочли? Так, чтобы удобно было и для форм и для бизнес логики? Есть идеи? .