Как вы проектируете уровень контроллера шаблона проектирования MVC в .NET
Вот мои мысли: Цель использования MVC - разделение проблем и тестируемость графической логики. Представление должно работать с разными моделями, а модель должна работать с разными представлениями.
Я думаю, что класс контроллера должен реализовывать интерфейс для имитации / тестирования, а представление должно вызывать методы контроллера через этот интерфейс. Но если мы это сделаем, тогда станет сложно обрабатывать элементы представления (текстовые поля, сетки и т. д.) В контроллере. Таким образом, эти элементы должны каким-то образом быть известны контроллеру.
1. Вы выставляете эти элементы интерфейса через интерфейс? Определите классы контроллера как частичные классы, чтобы контроллер мог напрямую обрабатывать элементы графического интерфейса (как насчет интерфейса)? Что вы делаете для решения этой проблемы?
2. В принципе, должен ли контроллер реализовывать более одного интерфейса? Один для представления, а другой для уровня модели, чтобы представление / модель могла работать с разными моделями / представлениями через контроллеры?
3. Слой модели также должен реализовывать интерфейс для имитации / тестирования?
Как мы можем лучше всего достичь целей тестирования со слабой связью в SoC? Поделитесь, пожалуйста, своим опытом / мыслями.
Ответы 2
Я считаю, что Посмотреть должен реализовывать интерфейс и передаваться в контроллер, обычно через конструктор. Таким образом, контроллер может использовать поля интерфейса представления для получения значений элементов управления, используемых представлением. Он также может использовать любую модель по вашему выбору. Это даст вам слабую связь между моделью и видом, который вы хотите.
То же самое можно сделать для модели, передав репозиторий для вашей модели через конструктор. Затем методы репозитория могут возвращать интерфейсы, которые должны реализовывать классы вашей модели.
Затем вы можете заставить контроллеры реализовать интерфейс и получить соответствующий контроллер во время выполнения с помощью контейнера IoC (который автоматически предоставит контроллеру соответствующий репозиторий представления и модели. Это позволит легко заменять контроллеры для замены текущая комбинация представления / модели для другого.Однако в целом я считаю, что в этом нет необходимости, потому что у меня всегда есть только один контроллер для каждого типа представления (интерфейс представления).
Отображение элементов графического интерфейса через интерфейс может быть длительной задачей, если в графическом интерфейсе их сотни. Но я не вижу другого варианта: частичная классификация затрудняет тестирование графического интерфейса пользователя и разрушает основы MVC. Таким образом, элементы для обработки можно передавать в качестве параметров в методах. Это может уменьшить объем кода.