Нужен ли MVC для клиент-серверного приложения?

Question

В настоящее время занимаюсь групповым проектом для колледжа на Java. Задача состоит в том, чтобы создать распределенную систему с нулевым доверием. Наша группа определилась с приложением для конференц-чата с использованием архитектуры клиент-сервер. Поскольку я присоединился к группе поздно, большая часть кода уже была завершена, и они решили разработать архитектуру MVC для проекта. У меня есть опыт работы с MVC через разработку Rails, и я могу оценить, насколько это удобно в этом контексте. Тем не менее, я не вижу преимуществ в том, чтобы использовать его так, как это было реализовано моей группой.

Существует два класса для клиента и сервера, каждый из которых содержит методы для отправки и получения дейтаграмм и поля, такие как сокеты, чтобы разрешить отправку. Существуют также классы ServerController и ClientController. Каждый из этих классов состоит только из одного поля (Сервер и Клиент соответственно), и все методы являются либо обертками для открытых методов Сервера или Клиента, либо простыми служебными методами. Примером может быть:

public void closeDownServer(){
    server.closeDownServer();
}

Мне это кажется совершенно бессмысленным, и что в данном случае MVC был реализован только для использования шаблона проектирования. Может кто-нибудь сказать мне, есть ли какая-либо польза от кодирования приложения таким образом? Есть ли необходимость в этих классах контроллеров вообще?

Answer 1

Целью MVC является предоставление абстракции для упрощения реализации последующих изменений и разъединения ваших компонентов.Возможно, именно поэтому вы считаете это бессмысленным ... потому что ваше приложение маленькое и простое.Если это так и останется, то MVC может быть просто добавлен в ваше приложение.Но если он будет расти, MVC может быть полезен для дальнейшей разработки.

Рассмотрим несколько случаев, которые могут проиллюстрировать, почему вы хотите использовать MVC или реализацию, которая позволяет моделировать и просматривать доступ друг к другу напрямую, безcontroller.

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

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

Answer 2

Контроллер означает, что вы можете изменить поведение привязки вида к модели (т.е. пользовательский ввод преобразуется контроллером в модель). В этом контексте я бы сказал, что контроллер, как правило, не нужен, так как вам не нужно будет менять это поведение в будущем.

Когда я разрабатываю игры, и мне нужно реализовать MVC, я обычно тоже опускаю контроллер (он объединяется с представлением).

Answer 3

с таким глубоким описанием невозможно сказать, действительно ли паттерн MVC действительно подходит для вашего дизайна.

Но я могу сказать следующее: есть паттерн, гораздо более важный паттерн, чем паттерн MVC -шаблон простоты: если что-то в вашем коде совершенно бесполезно и ничего не делает, избавьтесь от этого!Нет никакого смысла в том, чтобы иметь какой-то класс только из-за того, что когда-то так сказали некоторые авторитеты.

Довольно часто при реализации модели MVC я видел контроллер в сочетании с представлением, особенно когда приложение простое.Так что вы не одиноки, задавая этот вопрос.Позже, если возникает требование (например, несколько разных представлений), вы можете разделить контроллеры.