"… больше никто не ставит столько сносок в своих рекламных предложениях..." до банкам им ещё далеко)
Например, в Питере один банк гордо заявляет, что у него открылось новое направление вкладов для всех с процентной ставкой 12%*. А снизу приписка: *при единовременном пополнении счёта на 30 000 000 руб. И ещё куча разных *.
Для начала я бы отказался от типизированного приватного конструктора.
Далее написал бы класс для доступа к базе (аля слой data access). У класса есть метод: GetProducts(), который делает запрос в базу данных, получает результат и возвращает его в виде коллекции сущностей. Всё просто и понятно и легко тестируемо. Далее под ваши нужды уже совершенствование.
В этом подходе главное опыт. На моём первом проекте применили подобный подход к разработке, потом очень долго доводили до ума. Команда была большая и неопытная.
«Опять же в книге «Совершенный код» не советуют делать много наследуемых классов, а здесь получается такое увеличение на каждый валидатор. Не вдаваясь в подробности нужно себя спросить будет ли этих валидаторов больше семи разновидностей, и если их больше, то использовать другое решение.»
Может быть вы не правильно поняли ту идею, что я хотел донести, либо я её некорректно донёс. Базовый класс либо интерфейс нужен для того, чтобы у всех дочерних объектов была одинаковая сигнатура для метода — запуска валидации. Что касается наследования, то давайте посмотрим на .net framework, где все производные классы и интерфейсы наследуются от Object.
Что значит «получается такое увеличение на каждый валидатор», поясните.
«О чём и речь, это не просто решение нравится не нравится, это совершенно разные подходы к программированию. На интерфейсах валидатор сольётся с классом, который он проверяет, используя же наследование придётся включить объект валидатора в класс, и именно он будет торчать в списке валидаторов, а это уже совсем другая история.»
Признаться, я не совсем понимаю данную фразу, поясните пожалуйста.
Это уже выходит за рамки описанной мной ситуации.
Что касается такой ситуации, то, безусловно, вначале должна пройти клиентская валидация, затем данные пойти на сервер, после этого следует этап серверной валидации, и только в случае положительного результата сохранение данных.
«При грамотном использовании MVC, написать набор проверок через фабричные методы прийдется так же один раз — в контроллере, отвечающем за сохранение анкеты» — нужный фабричный метод будет написан 1 раз.
«Ведь если у вас анкета может сохраняться в десяти местах — неужели Вы считаете, что компоновщик избавит от ошибок?» — от ошибок валидации избавляют валидаторы, на которые написаны хорошие тесты.
По поводу примера в статье — опять же, самое простое, что пришло в голову. Для данного случая фабрика не нужна. Если имеем сложную систему, то уже надо об этом хорошо подумать.
Что касается добавления валидаторов:
допустим, у вас в анкете появилось новое поле, которое нужно проверять. Вы создаёте валидатор, добавляете новую ошибку в класс ResultCode и добавляете его в коллекцию композитного валидатора анкеты. Всё. Никаких индексов не нужно больше править.
Предложенный мной метод может применятся не только для валидации данных в клиент-серверных приложениях и не толко для валидации пользовательских данных. Подобный подход, например, можно использовать для проверки внутренних объектов на соответствие правилам бизнес логики.
Например, в Питере один банк гордо заявляет, что у него открылось новое направление вкладов для всех с процентной ставкой 12%*. А снизу приписка: *при единовременном пополнении счёта на 30 000 000 руб. И ещё куча разных *.
Далее написал бы класс для доступа к базе (аля слой data access). У класса есть метод: GetProducts(), который делает запрос в базу данных, получает результат и возвращает его в виде коллекции сущностей. Всё просто и понятно и легко тестируемо. Далее под ваши нужды уже совершенствование.
Может быть вы не правильно поняли ту идею, что я хотел донести, либо я её некорректно донёс. Базовый класс либо интерфейс нужен для того, чтобы у всех дочерних объектов была одинаковая сигнатура для метода — запуска валидации. Что касается наследования, то давайте посмотрим на .net framework, где все производные классы и интерфейсы наследуются от Object.
Что значит «получается такое увеличение на каждый валидатор», поясните.
«О чём и речь, это не просто решение нравится не нравится, это совершенно разные подходы к программированию. На интерфейсах валидатор сольётся с классом, который он проверяет, используя же наследование придётся включить объект валидатора в класс, и именно он будет торчать в списке валидаторов, а это уже совсем другая история.»
Признаться, я не совсем понимаю данную фразу, поясните пожалуйста.
Что касается такой ситуации, то, безусловно, вначале должна пройти клиентская валидация, затем данные пойти на сервер, после этого следует этап серверной валидации, и только в случае положительного результата сохранение данных.
Но я считаю, что в процессе валидации использование исключений некорректно.
Идёт проверка, если она непроходит, кидается exception. В примерах, которые погуглил, очень часто так делается.
«При грамотном использовании MVC, написать набор проверок через фабричные методы прийдется так же один раз — в контроллере, отвечающем за сохранение анкеты» — нужный фабричный метод будет написан 1 раз.
«Ведь если у вас анкета может сохраняться в десяти местах — неужели Вы считаете, что компоновщик избавит от ошибок?» — от ошибок валидации избавляют валидаторы, на которые написаны хорошие тесты.
Что касается добавления валидаторов:
допустим, у вас в анкете появилось новое поле, которое нужно проверять. Вы создаёте валидатор, добавляете новую ошибку в класс ResultCode и добавляете его в коллекцию композитного валидатора анкеты. Всё. Никаких индексов не нужно больше править.