Здравствуйте, gandjustas, Вы писали:
T>>Если классов много, N штук например, то вклад уже будет N * ЛЕПТА. Если мы для каждого класса подхачим ЛЕПТУ до меньшего значения лепта, то в совокупности это даст снижение на N * (ЛЕПТА — лепта). Что уже может иметь смысл. G>Это верно если все лепты независимы друг от друга.
Эта техника — суть локальное изменение внутри метода. Изменение кода внутри метода никаких зависимостей не порождает.
G>Но такого в жизни не бывает.
Бывает, на одном проекта, в котором я принимал участие, мы в течении пары дней таким образом очень неплохо снизили индекс.
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
T>>>Как она будет вызываться? Если какой-то сервис не станет ее вызывать, получим невалидные данные? G>>Валидация будет вызыватся при сохранении. Если у нас валидация задана декларативно, то можно через AOP заставить её проходить везде.
T>То есть в промежутке между модификацией и сабмитом сущность вполне может быть в невалидном состоянии, значит любые методы, оперирующие этой сущностью должны уметь работать с невалидной сущностью тоже.
Да, и это на самом деле сильно упрощает методы.
G>>>>>>service.CloseLocation(licationId), остальное происходит внутри метода. А тот кто вызывает этот метод не имеет возможности сохранить в базе этот location.
T>>>Если автор не захотел писать тест или автор — третье лицо, то смиримся с тем, что данные могут поломать? G>>А если автор не захотел писать проверки в классе?
T>А это уже проблема модели. Важно то, что имеющиеся проверки никогда не будут (не могут) быть проигнорированы.
Важно то что честное обеспечение всех проверок может быть очень тяжелым.
Пример с темже кастомером, у которого страна лежит в другой сущности.
есть у нас загруженный кастомер, у кторого zip валидируется определенным образом. Тут кто-то (другой пользователь) меняет связанную сущность, выставляя там другую страну. Загруженный кастомер об этом не знает, все приплыли.
Чтобы этого избежать кастомер должен каждый раз лазить в базу за валидацией зип-кода, на простом присваивании свойству. Или в память приложения должна быть загружена вся база. И то и другое — хреновые решения.
Еще одна ситуация: когда кастомер в процессе создания и еще не имеет ссылки на сущность со страной, как валидировать его zipCode?
Здравствуйте, gandjustas, Вы писали:
T>>То есть в промежутке между модификацией и сабмитом сущность вполне может быть в невалидном состоянии, значит любые методы, оперирующие этой сущностью должны уметь работать с невалидной сущностью тоже. G>Да, и это на самом деле сильно упрощает методы.
Разве. И как себя должен будет вести сервис списания остатков на складе если ему подсунули заказ с отрицательным количеством?
Увеличить складские остатки?
T>>А это уже проблема модели. Важно то, что имеющиеся проверки никогда не будут (не могут) быть проигнорированы. G>Важно то что честное обеспечение всех проверок может быть очень тяжелым.
А что делать?
G>Пример с темже кастомером, у которого страна лежит в другой сущности. G>есть у нас загруженный кастомер, у кторого zip валидируется определенным образом. Тут кто-то (другой пользователь) меняет связанную сущность, выставляя там другую страну. Загруженный кастомер об этом не знает, все приплыли.
G>Чтобы этого избежать кастомер должен каждый раз лазить в базу за валидацией зип-кода, на простом присваивании свойству. Или в память приложения должна быть загружена вся база. И то и другое — хреновые решения.
Или при сохранении проверить, что он пользовался валидной версией сущности, из которой он считал занчение country code. Варианты есть.
G>Еще одна ситуация: когда кастомер в процессе создания и еще не имеет ссылки на сущность со страной, как валидировать его zipCode?
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
G>>>>Просто представьте что такой кастомер. T>>>Какой такой? Если есть страна, то она где-то хранится. Следовательно её всегда можно узнать. G>>Замечательно, для загрузки кастомера из хранилища потребуется загрузка связанных сущностей.
T>Зачем? Требуемая сущность будет загружена по требованию, при валидации.
Чтобы сформировать объект валидатора для инстанцирования класса вам нужен CoutryCode, если эту связь оставлять ленивой, то это сильно усложнит валидаторы.
G>>Когда БЛ разбита на независимые сервисы тестировать становится лего и непринужденно. T>А когда у тебя domain model необходимость тестирования валидности отпадает.
А тестирование валидности не нужно, нужно проверить что сервис делает только то что должен.
G>>>>2)Есть тесты, которые проверят правильность работы логики
T>>>А так она (валидация) будет в одном месте — в модели. G>>Только это потребует гораздо больше "приседаний" чтобы валидация действительно везде работала, пример с zip code уже привели. T>В примере с zip-ом лишь сказали, что такая проблема была. Как её решили сказано не было.
Решается это тем, что валидация проводится там где необходимо. Тогда мы будем полностью контролировать количество обращений к базе за дополнительными параметрами.
G>>>>3)Саму валидацию на всех уровнях никто не отменял, но она содержится не классах сущностей, а вне их. T>>>Где? Когда вызывается? G>>Как минимум при сохранении, например по событию SavingChanges. T>Тем самым только расширяется интервал времени когда модель будет в невалидном состоянии. Зачем оно? Не лучше ли не допускать невалидности модели?
Совсем её не допускать при отсутствии пессимистичной блокировки (как в БД) не получится, только если не держать всю базу в памяти.
Гораздо проще устранить эффект от невалидности модели и не допустить сохранения невалидных сущностей.
Здравствуйте, Tissot, Вы писали:
G>>Но такого в жизни не бывает. T>Бывает, на одном проекта, в котором я принимал участие, мы в течении пары дней таким образом очень неплохо снизили индекс.
unit-тесты после такого снижения можно было бы значительно упростить, некоторые вообще выкинуть.
Лучший тест — это тест которого нет. Дзэнская мудрость.
Здравствуйте, gandjustas, Вы писали:
T>>Зачем? Требуемая сущность будет загружена по требованию, при валидации. G>Чтобы сформировать объект валидатора для инстанцирования класса вам нужен CoutryCode, если эту связь оставлять ленивой, то это сильно усложнит валидаторы.
Как усложнит?
G>>>Когда БЛ разбита на независимые сервисы тестировать становится лего и непринужденно. T>>А когда у тебя domain model необходимость тестирования валидности отпадает. G>А тестирование валидности не нужно, нужно проверить что сервис делает только то что должен.
Как же тогда убедиться, что сервис не поломал валидность? Каждый раз сабмитить в базу?
G>>>Только это потребует гораздо больше "приседаний" чтобы валидация действительно везде работала, пример с zip code уже привели. T>>В примере с zip-ом лишь сказали, что такая проблема была. Как её решили сказано не было. G>Решается это тем, что валидация проводится там где необходимо. Тогда мы будем полностью контролировать количество обращений к базе за дополнительными параметрами.
Вообще-то о zip-е писал Sinclair
T>>Тем самым только расширяется интервал времени когда модель будет в невалидном состоянии. Зачем оно? Не лучше ли не допускать невалидности модели? G>Совсем её не допускать при отсутствии пессимистичной блокировки (как в БД) не получится, только если не держать всю базу в памяти.
Почему не получится. Приведи вариант, когда не получится. И зачем для этого вся база в памяти?
G>Гораздо проще устранить эффект от невалидности модели и не допустить сохранения невалидных сущностей.
В одном месте упрощаешь, усложняется в другом. Теперь сервисам надо уметь работать с невалидными данными. И что в итоге проще?
Здравствуйте, gandjustas, Вы писали:
G>>>Но такого в жизни не бывает. T>>Бывает, на одном проекта, в котором я принимал участие, мы в течении пары дней таким образом очень неплохо снизили индекс.
G>unit-тесты после такого снижения можно было бы значительно упростить, некоторые вообще выкинуть.
Нельзя. На сoverage такая реорганизация не влияет.
G>
G>Лучший тест — это тест которого нет. Дзэнская мудрость.
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
T>>>То есть в промежутке между модификацией и сабмитом сущность вполне может быть в невалидном состоянии, значит любые методы, оперирующие этой сущностью должны уметь работать с невалидной сущностью тоже. G>>Да, и это на самом деле сильно упрощает методы.
T>Разве. И как себя должен будет вести сервис списания остатков на складе если ему подсунули заказ с отрицательным количеством? T>Увеличить складские остатки?
А откуда пришел заказ?
Если из базы, то как он туда попал?
Если от PL, то срочно идти смотреть тесты и выяснять по какой причине заказ с отрицательным количеством оттуда пришел, почему не были провалидированы введеные пользователем данные.
Даже если все забили на валидацию, то заказ будет провалидирован при сохранении в базу и бизнес-транзакция будет отменена.
Валидацию по хорошему и в PL надо делать, но так чтобы она быстро работала.
T>>>А это уже проблема модели. Важно то, что имеющиеся проверки никогда не будут (не могут) быть проигнорированы. G>>Важно то что честное обеспечение всех проверок может быть очень тяжелым. T>А что делать?
Не делать проверки везде.
G>>Пример с темже кастомером, у которого страна лежит в другой сущности. G>>есть у нас загруженный кастомер, у кторого zip валидируется определенным образом. Тут кто-то (другой пользователь) меняет связанную сущность, выставляя там другую страну. Загруженный кастомер об этом не знает, все приплыли. G>>Чтобы этого избежать кастомер должен каждый раз лазить в базу за валидацией зип-кода, на простом присваивании свойству. Или в память приложения должна быть загружена вся база. И то и другое — хреновые решения.
T>Или при сохранении проверить, что он пользовался валидной версией сущности, из которой он считал занчение country code. Варианты есть.
Ключевое слово — при сохранении. Фактическое принятие решение о валидности сущности переносится на один конкретный момент — сохранение данных. То есть речь о постоянной валидности сущности уже не идет.
G>>Еще одна ситуация: когда кастомер в процессе создания и еще не имеет ссылки на сущность со страной, как валидировать его zipCode? T>Я не знаю, зависит от бизнес-логики.
Это как раз вопрос дизайна. На форуме "архитектура" было такое обсуждение. Варианты — плодить builder или data object. Но тогда возникает смысловое дублирование.
Здравствуйте, gandjustas, Вы писали:
G>Даже если все забили на валидацию, то заказ будет провалидирован при сохранении в базу и бизнес-транзакция будет отменена. G>Валидацию по хорошему и в PL надо делать, но так чтобы она быстро работала.
Что-то я подзадолбался отвечать. Чего в сотый раз перетира domain model vs something else? Все равно все останутся при своих мнениях, т.к. плюсы есть и там и там.
Давай завяжем с этим.
G>>>Еще одна ситуация: когда кастомер в процессе создания и еще не имеет ссылки на сущность со страной, как валидировать его zipCode? T>>Я не знаю, зависит от бизнес-логики. G>Это как раз вопрос дизайна. На форуме "архитектура" было такое обсуждение. Варианты — плодить builder или data object. Но тогда возникает смысловое дублирование.
У нас у таких сущностей есть состояние Draft. В этом состоянии проверки не делаются, т.е. фактически она работает как data object. После завершения инициализации сущность переходит в состояние Ready (с валидацией). Переход обратно невозможен.
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
T>>>Зачем? Требуемая сущность будет загружена по требованию, при валидации. G>>Чтобы сформировать объект валидатора для инстанцирования класса вам нужен CoutryCode, если эту связь оставлять ленивой, то это сильно усложнит валидаторы.
T>Как усложнит?
связанная сущность, хранящаяя страну — Region
ZipCodeValidationStrategyFacory.GetByCountryCode(Region.CountryCode) //здесь cущность Region должна быть загружена
Если захочется связь ленивой сделать то придется усложнить валидатор. Можно валидатор создавать при первом обращении, но тогда не факт что будет контекст существовать в момент загрузки связанной сущности (у нас всего лишь происходит изменение свойтва).
G>>>>Когда БЛ разбита на независимые сервисы тестировать становится лего и непринужденно. T>>>А когда у тебя domain model необходимость тестирования валидности отпадает. G>>А тестирование валидности не нужно, нужно проверить что сервис делает только то что должен. T>Как же тогда убедиться, что сервис не поломал валидность? Каждый раз сабмитить в базу?
А зачем нам это? Если каждый маленький кусочек работает правильно и интеграционные тесты показывают что основные сценарии проходят успешно (вместе с записью в базу), то все ок.
T>>>Тем самым только расширяется интервал времени когда модель будет в невалидном состоянии. Зачем оно? Не лучше ли не допускать невалидности модели? G>>Совсем её не допускать при отсутствии пессимистичной блокировки (как в БД) не получится, только если не держать всю базу в памяти. T>Почему не получится. Приведи вариант, когда не получится. И зачем для этого вся база в памяти?
Дык пример с кастомером и регионом. Валидность зип-кода кастомера зависит от страны, хранящейся в сущности регион. Мы работаем с кастомером, а другой пользователь в этот момент меняет страну реиона. Валидность кастомера нарушена, а потимистичная блокировка нам не поможет ибо регион не был изменен в нашем сеансе.
Если вся база в памяти, то мы можем контролировать каждое изменение.
G>>Гораздо проще устранить эффект от невалидности модели и не допустить сохранения невалидных сущностей. T>В одном месте упрощаешь, усложняется в другом. Теперь сервисам надо уметь работать с невалидными данными. И что в итоге проще?
Работать с невалидными данными проще, не нужно проверок, обработок исключений и прочего.
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
G>>>>Но такого в жизни не бывает. T>>>Бывает, на одном проекта, в котором я принимал участие, мы в течении пары дней таким образом очень неплохо снизили индекс.
G>>unit-тесты после такого снижения можно было бы значительно упростить, некоторые вообще выкинуть.
T>Нельзя. На сoverage такая реорганизация не влияет.
Ну если у вас тесты для кавереджа, тогда да. Если тестируются сценарии использования, то количество тестов уменьшится.
Например в вашем коде после рефакторинга можно сделать всего два теста, место тестов на каждый if.
G>>
G>>Лучший тест — это тест которого нет. Дзэнская мудрость.
Здравствуйте, Tissot, Вы писали:
G>>>>Еще одна ситуация: когда кастомер в процессе создания и еще не имеет ссылки на сущность со страной, как валидировать его zipCode? T>>>Я не знаю, зависит от бизнес-логики. G>>Это как раз вопрос дизайна. На форуме "архитектура" было такое обсуждение. Варианты — плодить builder или data object. Но тогда возникает смысловое дублирование.
T>У нас у таких сущностей есть состояние Draft. В этом состоянии проверки не делаются, т.е. фактически она работает как data object. После завершения инициализации сущность переходит в состояние Ready (с валидацией). Переход обратно невозможен.
Моя плакать...
У меня для таких случаев ничего дополнительно делать не надо
Здравствуйте, gandjustas, Вы писали:
T>>Как усложнит? G>связанная сущность, хранящаяя страну — Region G>
G>ZipCodeValidationStrategyFacory.GetByCountryCode(Region.CountryCode) //здесь cущность Region должна быть загружена
G>
G>Если захочется связь ленивой сделать то придется усложнить валидатор. Можно валидатор создавать при первом обращении, но тогда не факт что будет контекст существовать в момент загрузки связанной сущности (у нас всего лишь происходит изменение свойтва).
Чего-то как-то у тебя все сложно получается. Валидатор никак не связан с ленивостью чего-либо. Он просто строку проверяет. Или я опять чего-то не вкуриваю?
G>>>А тестирование валидности не нужно, нужно проверить что сервис делает только то что должен. T>>Как же тогда убедиться, что сервис не поломал валидность? Каждый раз сабмитить в базу? G>А зачем нам это? Если каждый маленький кусочек работает правильно и интеграционные тесты показывают что основные сценарии проходят успешно (вместе с записью в базу), то все ок.
Значит все ок. Здолбался. Давай не будем больше это обсуждать.
Я могу написать тут еще аргументов, но на каждое ты дашь свой вариант ответа, чтобы остаться при мнении, и эти варианты будут работать.
Но есть также и другой вариант — domain model. Он тоже не лишен недостатков, на некоторые из них в частности тут уже указывали. Но и эти недостатки находят свое решение.
Так что давай каждый останется при своем и разойдемся с миром, чтобы не скатиться до поливания друг друга грязью, как это делал один из участников дискуссии.
G>Дык пример с кастомером и регионом. Валидность зип-кода кастомера зависит от страны, хранящейся в сущности регион. Мы работаем с кастомером, а другой пользователь в этот момент меняет страну реиона. Валидность кастомера нарушена, а потимистичная блокировка нам не поможет ибо регион не был изменен в нашем сеансе. G>Если вся база в памяти, то мы можем контролировать каждое изменение.
Тогда встанет другая проблема — как обеспечить валидность при конкурентном доступе. А эта проблема еще хуже всех перечисленных до этого.
G>>>Гораздо проще устранить эффект от невалидности модели и не допустить сохранения невалидных сущностей. T>>В одном месте упрощаешь, усложняется в другом. Теперь сервисам надо уметь работать с невалидными данными. И что в итоге проще? G>Работать с невалидными данными проще, не нужно проверок, обработок исключений и прочего.
Здравствуйте, gandjustas, Вы писали:
T>>Нельзя. На сoverage такая реорганизация не влияет. G>Ну если у вас тесты для кавереджа, тогда да. Если тестируются сценарии использования, то количество тестов уменьшится.
каверидж — это формальная характеристика которая показывает какие участки кода были вызваны из тестов. на основе этой характеристики конечно же нельзя делать вывод, что код протестирован, но на основе того, что покрытия нет можно абсолютно точно определить что не протестировано.
G>Например в вашем коде после рефакторинга можно сделать всего два теста, место тестов на каждый if.
Нельзя. Нужно чтобы тест проверил что каждый action работает корректно. А это как минимум 4 теста (по кол-ву action-ов).
G>>Например в вашем коде после рефакторинга можно сделать всего два теста, место тестов на каждый if. T>Нельзя. Нужно чтобы тест проверил что каждый action работает корректно. А это как минимум 4 теста (по кол-ву action-ов).
От них никуда не денешься. Я имел ввиду метод, который вызывает экшены.
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
T>>>Как усложнит? G>>связанная сущность, хранящаяя страну — Region G>>
G>>ZipCodeValidationStrategyFacory.GetByCountryCode(Region.CountryCode) //здесь cущность Region должна быть загружена
G>>
G>>Если захочется связь ленивой сделать то придется усложнить валидатор. Можно валидатор создавать при первом обращении, но тогда не факт что будет контекст существовать в момент загрузки связанной сущности (у нас всего лишь происходит изменение свойтва).
T>Чего-то как-то у тебя все сложно получается. Валидатор никак не связан с ленивостью чего-либо. Он просто строку проверяет. Или я опять чего-то не вкуриваю?
Чтобы проверить строку он должен знать как её проверить. Чтобы знать как он должен знать CountryCode, чтобы знать CountryCode нужно подгрузить связанную сущность, в которой лежит CountryCode. Создавать валидатор один раз во время создания объекта нельзя, потому что в связанном регионе может CountryCode измениться из другого контекста и кастомер об этом не узнает. Как обеспечить по-настоящиму валидное состояние кастомера при каждом изменении zip code, чтобы не лазить каждый раз в базу?
G>>>>А тестирование валидности не нужно, нужно проверить что сервис делает только то что должен. T>>>Как же тогда убедиться, что сервис не поломал валидность? Каждый раз сабмитить в базу? G>>А зачем нам это? Если каждый маленький кусочек работает правильно и интеграционные тесты показывают что основные сценарии проходят успешно (вместе с записью в базу), то все ок.
T>Значит все ок. Здолбался. Давай не будем больше это обсуждать. T>Я могу написать тут еще аргументов, но на каждое ты дашь свой вариант ответа, чтобы остаться при мнении, и эти варианты будут работать. T>Но есть также и другой вариант — domain model. Он тоже не лишен недостатков, на некоторые из них в частности тут уже указывали. Но и эти недостатки находят свое решение.
Ну так я и говорю что все можно сделать неправильно и оно будет работать.
T>Так что давай каждый останется при своем и разойдемся с миром, чтобы не скатиться до поливания друг друга грязью, как это делал один из участников дискуссии.
Не переживайте, он всегда так разговаривает.
G>>Дык пример с кастомером и регионом. Валидность зип-кода кастомера зависит от страны, хранящейся в сущности регион. Мы работаем с кастомером, а другой пользователь в этот момент меняет страну реиона. Валидность кастомера нарушена, а потимистичная блокировка нам не поможет ибо регион не был изменен в нашем сеансе. G>>Если вся база в памяти, то мы можем контролировать каждое изменение. T>Тогда встанет другая проблема — как обеспечить валидность при конкурентном доступе. А эта проблема еще хуже всех перечисленных до этого.
Ну система блокировок как в БД.
G>>>>Гораздо проще устранить эффект от невалидности модели и не допустить сохранения невалидных сущностей. T>>>В одном месте упрощаешь, усложняется в другом. Теперь сервисам надо уметь работать с невалидными данными. И что в итоге проще? G>>Работать с невалидными данными проще, не нужно проверок, обработок исключений и прочего.
T>Есть и другое мнение. См. Defensive programming
Defensive programming — это когда мы считаем что отовсюду нас хотя нае**ть, а мы тут предлагаем просто игнорировать факт невалидности сущностей (на самом деле данных, которые по идеологии не могут быть невалидными) пока это не станет важно.
Это важно в первую очередь при сохранении, во вторую очередь важно в UI (PL) или другом месте откуда приходят данные чтобы обеспечить хороший feedback.
G>>>ZipCodeValidationStrategyFacory.GetByCountryCode(Region.CountryCode) //здесь cущность Region должна быть загружена
G>>>
G>>>Если захочется связь ленивой сделать то придется усложнить валидатор. Можно валидатор создавать при первом обращении, но тогда не факт что будет контекст существовать в момент загрузки связанной сущности (у нас всего лишь происходит изменение свойтва).
T>>Чего-то как-то у тебя все сложно получается. Валидатор никак не связан с ленивостью чего-либо. Он просто строку проверяет. Или я опять чего-то не вкуриваю? G>Чтобы проверить строку он должен знать как её проверить. Чтобы знать как он должен знать CountryCode,
Валидатор не должен он просто преверяет. CountryCode должен знать тот, что получает валидатор. См. код выше.
T>>Значит все ок. Здолбался. Давай не будем больше это обсуждать. T>>Я могу написать тут еще аргументов, но на каждое ты дашь свой вариант ответа, чтобы остаться при мнении, и эти варианты будут работать. T>>Но есть также и другой вариант — domain model. Он тоже не лишен недостатков, на некоторые из них в частности тут уже указывали. Но и эти недостатки находят свое решение. G>Ну так я и говорю что все можно сделать неправильно и оно будет работать.
Это не неправильно. Это просто по другому. На эту тему я больше не буду отвечать.
T>>Есть и другое мнение. См. Defensive programming G>Defensive programming — это когда мы считаем что отовсюду нас хотя нае**ть, а мы тут предлагаем просто игнорировать факт невалидности сущностей (на самом деле данных, которые по идеологии не могут быть невалидными) пока это не станет важно.
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали: G>>>>
G>>>>ZipCodeValidationStrategyFacory.GetByCountryCode(Region.CountryCode) //здесь cущность Region должна быть загружена
G>>>>
G>>>>Если захочется связь ленивой сделать то придется усложнить валидатор. Можно валидатор создавать при первом обращении, но тогда не факт что будет контекст существовать в момент загрузки связанной сущности (у нас всего лишь происходит изменение свойтва).
T>>>Чего-то как-то у тебя все сложно получается. Валидатор никак не связан с ленивостью чего-либо. Он просто строку проверяет. Или я опять чего-то не вкуриваю? G>>Чтобы проверить строку он должен знать как её проверить. Чтобы знать как он должен знать CountryCode,
T>Валидатор не должен он просто преверяет. CountryCode должен знать тот, что получает валидатор. См. код выше.
Разницы нету, можно писать new ZipCodeValidator(Region.CountryCode), проблема останется таже. за время жизни кастомера валидатор может стать ... эээ ... невалидным.
Кстати, при наличии CountryCode внутри кастомера невозжножно будет поменять этот самый CountryCode, потому что сразуже станет невалидным ZipCode (ну если у них случано не совпадут правила валидации).
Здравствуйте, gandjustas, Вы писали:
T>>Валидатор не должен он просто преверяет. CountryCode должен знать тот, что получает валидатор. См. код выше. G>Разницы нету, можно писать new ZipCodeValidator(Region.CountryCode), проблема останется таже. за время жизни кастомера валидатор может стать ... эээ ... невалидным.
Посмотри код, где он создается. Нет необходимости его хранить. Он легковесный.
G>Кстати, при наличии CountryCode внутри кастомера невозжножно будет поменять этот самый CountryCode, потому что сразуже станет невалидным ZipCode (ну если у них случано не совпадут правила валидации).
