Как заставить контроллер изменять свое поведение в зависимости от вида?

Question

Если из одного просмотра пользователь вводит некоторые недействительные данные, например ::

E-mail: bill@apple.com

тогда я хочу, чтобы контроллер:

• не поместить данные в модель
• цвет текстового поля красноватый
• не позволяет пользователю сохранять

Но возможно, что если пользователь вводит те же недопустимые данные в другое представление, я хочу, чтобы контроллер:

• поместить данные в модель
• цвет текстового поля красноватый
• позволяет пользователю сохранять

Но возможно, что если пользователь вводит те же недопустимые данные в другое представление, я хочу, чтобы контроллер:

• поместить данные в модель
• Цвет текстового поля Голубоватый
• позволяет пользователю сохранять

И возможно, что другой вид будет:

• поместить данные в модель
• оставить текстовое поле неокрашенным
• позволяют пользователю сохранять

И возможно, что другой вид будет:

• автокоррекция данных, размещение их в модели
• цвет надписи красноватый
• позволяют пользователю иметь

И для другого вида возможно:

• автокоррекция данных, размещение их в модели
• обновление представление с новыми данными
• цвет текстовое поле голубоватое
• разрешить пользователю сохранять

[до бесконечности]

Без использования n-контроллеров для n-представлений, как мне это сделать?

---

Обновление

Я собирался задать новый вопрос по stackoverflow: «Как заставить контроллер изменять свое поведение в зависимости от представления?» Но потом я понял, что у меня уже используется точно такой же заголовок вопроса.

Сегодняшний пример:

• Если введенные данные слишком длинные для некоторых частей некоторых таблиц базы данных, в которые они будут входить, выполните проверку и отклоните сохранение.

• , если данные не поступают из другого представления. В этом случае автоматически обрезать определенные поля, чтобы соответствовать правилам базы данных

• , если данные не поступают из другого представления. В этом случае требуется, чтобы база данных выдавала truncated исключение

Так много практических проблем с MVC, которые я никогда не видел, решены в книгах / статьях / блогах, которые я прочитал - неудивительно, что я не использую их.

Answer 1

Ваши примеры могут быть несколько обобщены в представлении, как было предложено, однако, некоторые варианты использования действительно запрашивают различные контроллеры imho. Также вы можете попробовать добавить немного логики в модели. Цвета - это просто, контроллеры должны решить, целесообразно ли сохранять данные в моделях, если эти данные не имеют какого-либо свойства, решать, сохранять их или нет, пусть это на контроллерах, возможно, разные. Автокоррекции должны быть во взглядах и помощниках. Это только мое мнение.

Answer 2

Логика того, что должно быть сделано с каждым представлением, должна где-то находиться. Я бы порекомендовал вам расширить представление этой информацией, вместо того, чтобы использовать несколько контроллеров или создать какое-то отображение между конфигурацией view => в одном контроллере.

Я не знаю, что эти представления представляют с точки зрения вашего домена, но похоже, что представление выглядит командным, если недопустимые данные могут быть сохранены в модели, если автокоррекция разрешена, визуальная индикация недопустима данные и т. д. Почему бы не расширить возможности этой информации?

Каждое из этих представлений будет иметь определенные свойства.

acceptsInvalidData => boolean, place invalid data to model
requiresAutoCorrection => boolean, auto-correct the data
synchronizeWithModel => boolean, always keep the view in sync with the model
allowsSavingInvalidData => boolean, allow saving of invalid data
invalidDataIndicator => string:color, how to color view for invalid data

С учетом этих 5 свойств (может отсутствовать одно или два) контроллер может инициировать последовательность действий, которые будут уникальным образом обрабатывать каждый тип представления. Представлению придется выставить себя или свойства контроллеру.

Answer 3

Подведем итог проблемы:

1. Кажется, вы хотите N различного поведения, не имея N контроллеров .

2. Вы не хотите тесно связывать представления и контроллеры (нет 1 <-> 1 отношения), но вам нужен контроллер , чтобы иметь сильный и разнообразный контроль над поведением каждого представления .

Позвольте мне сформулировать это по-другому:

1. Кажется, вы хотите N различного поведения, не имея N объектов .

2. Вы не хотите тесно связывать объекты A и B (нет 1 <-> 1 отношения), но вы хотите B объект имеет различный жесткий контроль над поведением каждого объекта .

Вот как я вижу эти 2 вопроса:

1. Это не проблема MVC, это классическая проблема программного обеспечения: вам нужно или N объектов иметь N различных поведений, или вам нужно параметризовать поведения, чтобы вы могли выявить общность (например, подход, предложенный Анурагом) иметь менее N отдельных объектов и / или прибегать к гигантской формулировке случая. : -)

2. Это не проблема MVC, а один из компромиссов. MVC позволяет разделить код M, V и C, чтобы упростить будущие изменения (например, изменение или добавление представлений). Но компромисс не свободен, компоненты обязательно должны иметь меньше знаний и контроля друг над другом. Либо вы отказываетесь от контроллера, который жестко контролирует представления (нет N различных видов поведения), либо вы отказываетесь от разделения между C и V (например, допускаете 1 <-> 1 тесно связанные представления- контроллеры).

Конечно, с MVC был большой успех в отделении Ms от V и C, но меньший успех в отделении V и C друг от друга. Я думаю, что современные адаптивные интерфейсы требуют объединения представлений и контроллеров, или начались по-другому, не стоит усилий и сложности, чтобы сильно изолировать представления и контроллеры. Этот модифицированный M(VC) подход работал гораздо лучше для меня в реальном мире.