Как вы разрабатываете уровень контроллера шаблона проектирования MVC в .NET

Question

Вот мои мысли: Цель использования MVC - разделение проблем и тестируемость логики графического интерфейса. Вид должен уметь работать с разными моделями, а модель должна уметь работать с разными видами.

Я думаю, что класс контроллера должен реализовывать интерфейс по причинам насмешки / тестирования, и представление должно вызывать методы контроллера через этот интерфейс. Но если мы сделаем это, тогда станет трудно обрабатывать элементы представления (текстовые поля, сетки и т. Д.) В контроллере. Таким образом, эти элементы должны быть как-то известны контроллеру.

1. Вы выставляете эти элементы графического интерфейса через интерфейс? Определите классы контроллера как частичные классы, чтобы контроллер мог напрямую обрабатывать элементы графического интерфейса (как насчет интерфейса)? Что вы делаете, чтобы решить эту проблему?

2. По сути, должен ли контроллер реализовывать более одного интерфейса? Один для вида, а другой для уровня модели, чтобы вид / модель могли работать с различными моделями / видами через контроллеры?

3. Модельный слой также должен реализовывать интерфейс для макета / тестирования?

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

Answer 1

Предоставление элементов графического интерфейса через интерфейс может быть долгой задачей, если в графическом интерфейсе их сотни. Но я не вижу другого варианта: частичная классификация усложнит тестирование логики графического интерфейса, а также разрушит основы MVC. Таким образом, элементы для обработки могут быть переданы в качестве параметров в методы. Это может уменьшить объем кодирования.

Answer 2

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

То же самое можно сделать для модели, передав репозиторий для вашей модели через конструктор. Методы хранилища могут затем возвращать интерфейсы, которые должны реализовывать ваши классы моделей.

Затем вы можете заставить контроллеры реализовать интерфейс и получить соответствующий контроллер во время выполнения, используя контейнер IoC (который автоматически предоставит контроллеру соответствующий вид и репозиторий модели. Это позволит вашим контроллерам легко заменяться. заменить текущую комбинацию вида / модели на другую. В целом, однако, я нахожу это ненужным, потому что у меня когда-либо только один контроллер для каждого типа вида (интерфейс вида).