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


T>Откуда CustomerManager и как он может помешать изменить Customer-а напрямую?
Как откуда? Это и есть класс, в котором сосредоточены методы управления кастомерами.
Помешать он сам конечно не может, в том смысле, что у админа-злодея всегда есть шанс полезть в базу напрямую.
А вот запретить из прикладного кода вызовы апдейт-стейтментов можно в том числе и при помощи FxCop.
Это если не хватает культуры программирования.
Нужно просто отделить случайные ошибки от преднамеренных действий.

S>>А если подумать головой, то окажется, что зип-код нужен только в тот момент, когда выполняется отгрузка товара. Если кастомер хочет заказать и заплатить, то нет никакой причины требовать от него валидность ненужного сейчас зип-кода.

T>Ну это скорее аргумент в пользу изменени логики валидации — она должна запускаться только при определенном статусе заказа.
Это приведет к тому, что в приложении вообще не будет повторно используемого кода. Потому что в логику валидации зашито слишком много подробностей про окружение. А всего-то надо было применить регекс в нужный момент.