MVC Design Pattern

Question

Я много читал о шаблоне проектирования MVC, но некоторые вещи до сих пор не ясны. Я знаю, что «Модель» предназначена для данных и бизнес-логики, «Вид» предназначен для представления, а «Контроллер» предназначен для использования «Модели» и предоставления «Представлений» (т. Е. C - канал связи между M и V).

Теперь у меня есть следующая проблема, я хочу, чтобы решить:

Проблема: Веб-приложение принимает в качестве входных данных, список узлов от пользователя. Затем модель используется для создания графика (т. Е. Диаграммы структуры данных, а не графика x-y) из этих узлов (с использованием базы данных).

Затем я использую алгоритм Дейкстры, чтобы узнать кратчайший путь от исходного узла до конечного узла в этом графе. Использую ли я алгоритм Дейкстры в Модели или Контроллере?

Я думаю, что я должен использовать слой «Модель», потому что сам «самый короткий путь» - это данные.

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

Может ли кто-нибудь дать мне правильный ответ? Пока я собираюсь реализовать алгоритм Дейкстры в модельном слое.

Answer 1

Да, вы правы. Вы должны поместить свой алгоритм Дейкстры в модель. Причина в том, что вы можете использовать другой алгоритм для поиска кратчайшего пути завтра, поэтому в этом случае вам не нужно менять свой контроллер, просто измените логику класса, реализующего алгоритм. И результат этого алгоритма должен быть включен в поле зрения.

Answer 2

МОЕГО личное предложение является то, что Go с контроллером частью , потому что если вы используете часть модели это увеличит время выполнения, потому что после того, как все модели будут управление вызовом контроллера

и для больного алгоритма пути есть нет каких-либо изменений базы данных мы должны просто играть с данными на основе алгоритма

так мое личное чувство пойти с контроллером вместо модели

благодаря

Answer 3

Вопрос в том, почему контроллер, а не модель. Его вопрос дизайна более чем вопрос кодирования. Он будет работать на контроллере и модели. Но если вам понадобится больше нескольких контроллеров в будущем (например, используйте разные алгоритмы для кратчайшего пути), и вам нужна ваша модель для выбора контроллера во время выполнения, то он должен быть в контроллере. Если алгоритм «контроллеры» что-то еще, то он должен быть в модели. Возможно, вы хотите использовать кратчайший путь, используя только этот алгоритм, но в будущем вы хотите использовать разные типы данных. Итак, манипулятор данных должен находиться в контроллере.

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

Изменение здесь. Что в будущем вы ожидаете изменить, поскольку новые функции добавляются в продукт.

Answer 4

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

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

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

Answer 5

Ну, если вы читаете Head First Servlets и Jsps, вы обнаружите, что ваша логика лучше всего хранится в модели. Почему я так говорю: Если завтра вы думаете об изменении View Layer вашего приложения, у меня должна быть модель, готовая сделать это. Например: красота MVC дает вам силу гибкости. Завтра я хочу, чтобы мое приложение запускалось с рабочего стола на веб-сайт или наоборот. Я могу написать всю свою логику отдельно. Шаблон разработки стратегии хорош для расширения, но затем он снова хочет, чтобы у вас была логика, написанная в модели.