MVC - Должны ли быть основные View, Model и Controller или они должны быть специфичными для реализации? - PullRequest
Новая
       6

MVC - Должны ли быть основные View, Model и Controller или они должны быть специфичными для реализации?

0 голосов
/ 01 февраля 2019

Мне интересна концепция, а не реализация.Рассмотрим сценарий CarBookingRequest, когда пользователь через интерфейс запрашивает бронирование автомобиля.Давайте обсудим это при следующем ограничении и рассмотрим только View в перспективе, оставив Controller и Model простыми:

  • Существует один класс / код контроллера, который содержит все функции, представляющие соответствующие действия.
  • Существует один класс / код модели, который работает только с одной базой данных с несколькими таблицами (без других моделей данных)

Может быть много интерфейсов, через которые можно сделать запрос:

1.Настольное приложение

Пользователь нажимает Button, который запускает событие Click, которое, в свою очередь, запрограммировано для совершения вызова на BookingController с запросом NewBooking.Что-то вроде: 

 Event OnClick() { 
    C = New BookingController
    C.Request('NewBooking')
 }

2.Мобильное приложение

Пользователь нажимает Button, который запускает событие Touch, которое, в свою очередь, запрограммировано для вызова того же BookingController с запросом NewBooking.Что-то вроде: 

 EventListener OnTouch() { 
    C = New BookingController
    C.Request('NewBooking')
 }

3.Торговый автомат

Пользователь нажимает PushButton на автомате, который запускает событие, которое запрограммировано заранее, чтобы позвонить тому же BookingController с запросом NewBooking.Что-то вроде: 

 Event OnPress() { 
    C = New BookingController
    C.Request('NewBooking')
 }

Предположим, аналогичная реализация для Веб-интерфейс и Сервисный интерфейс , где запрос сделан другой системой или запланированной задачей.Очевидно, что все эти реализации представляют собой разные версии BookingViews , написанные на самых разных языках и платформах.Теперь, если я знал эти реализации заранее, и я делаю бронирование MVC, каким должен быть мой класс View, Controller и Model?или сколько?и почему?

Должен ли я иметь класс "Main" BookingView с такой функцией, как: 

 Function CallController(Command) { 
    If Command = 'NewBooking' {
       Return New BookingController
    }
    or some good implementation of controller/action registry to fetch appropriate controller
 }

, и каждый конкретный View должен по очереди вызывать эту функцию, котораязатем назовем BookingController как: 

 Event OnClick { 
    C = MainView.CallConroller('NewBooking')
 }

Или каждый View должен вызывать контроллер отдельно по-своему?

Может быть, слишком много вопросов, но я придерживаюсь мнениячто мой View, Controller и Model должны быть многоразовыми, и каждый новый Interface (мобильный, машинный или сетевой) должен требовать только определенной обработки View (событий или дисплеев), в то время как код подключения и выборки данных остается без изменений.

1 Ответ

0 голосов
/ 01 февраля 2019

Основная идея шаблонов MVC состоит в том, чтобы отделить три аспекта приложения - модель, представление и контроллер - от друг от друга.

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

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

  • Ваша модель не должна знать о контроллере .Задача Model - осуществить бронирование автомобиля .Он не знает, что с ним делается (например, хочет ли контроллер получить к нему доступ, а затем передать его кому-то еще или около того).Например, он может иметь такой интерфейс, как

    CarBooking:

    constructor ();

    book ();

    unbook ();

    ...

Он выполняет бизнес-логику построения запроса, бронирования запроса или удаления бронирования. Период .

Как вам этого добиться, правильное разделение модели, вида и контроллера?Ну, один из способов - начать изнутри, а затем двигаться наружу.То есть начните с Модели, затем контроллера, затем просмотрите.В действительности вы можете делать это не в таком порядке, поскольку вам необходимо учитывать все эти аспекты.Но то, что я говорю, более логично.

...