Java MVC - Не похоже, что я понял

Question

Будучи новичком в программировании, я всегда сталкиваюсь с проблемами, когда сталкиваюсь со стенами. В настоящее время одной из стен являются объекты взаимозависимости.

Как вы можете видеть из моей истории вопросов, я в настоящее время работаю над приложением Blackberry, в котором я реализовал то, что я называю MVC Pattern, но я не совсем так думаю.

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

альтернативный текст http://www.ibm.com/developerworks/wireless/library/wi-arch6/theoretical.gif

Пожалуйста, не прекращайте читать :) Я показываю вам часть своего кода, который содержит некоторые специфические для blackberry вещи, но вы должны увидеть, что я делаю.

Основная точка входа для моего приложения

public class ContactManager extends UiApplication
{
    private static ContactManagerMainScreenModel MainScreenModel = new ContactManagerMainScreenModel();
    private static ContactManagerMainScreen MainScreenView = null;

    public static void main(String[] args)
    {
        new ContactManager().enterEventDispatcher();
    }
    public ContactManager()
    {   
        MainScreenView = new ContactManagerMainScreen(MainScreenModel);
        // Displays the Splashscreen then opens the Mainscreen 
        new SplashScreen(UiApplication.getUiApplication(), MainScreenView);
    }
}

Модель главного экрана

public class ContactManagerMainScreenModel
{
    ContactManagerMainScreen v;
    // Loading Local Storage
    LocalContactStorage LocalContactStorage = new LocalContactStorage();

    // Define Data List
    private Vector vContacts_Favorites;

    public void register(ContactManagerMainScreen v)
    {
        this.v = v;
    }
    // Retrieve Favorite Contacts from Persistant Storage
    public Vector getFavoriteContactsFromLocalStorage()
    {
        vContacts_Favorites = LocalContactStorage.getFavoriteContactsFromLocalStorage();
        return vContacts_Favorites;
    }
    // Put Retrieve Favorite Contacts from Persistant Storage
    public void saveFavoriteContactsToLocalStorage()
    {
        LocalContactStorage.saveFavoriteContactsToLocalStorage(vContacts_Favorites);
    }
}

MainScreenController

public class ContactManagerMainScreenController 
{
    private ContactManagerMainScreenModel _model = null;
    private ContactManagerMainScreen _view = null;

    public ContactManagerMainScreenController(ContactManagerMainScreen view, ContactManagerMainScreenModel model)
    {
        this._model = model;
        this._view = view;
    }

    public void HideFavoriteList()
    {
        if( this._view._ContactList.getManager() != null)
        {
            this._view._ContactList.getManager().delete(this._view._ContactList);
        } else
        {
            this._view._bottom_box.add(this._view._ContactList);
        }
    }
}

Все еще там? Хорошо ...

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

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

Я не могу создать контроллер до объявления представления. Без требования разрешить контроллеру изменять элементы UIE, это не будет проблемой (как показано на графике).

Что я делаю сейчас, так это то, что представление создает контроллер

controller = new ContactManagerMainScreenController(this , model);

Имеет ли это смысл? Я хочу понять шаблон, поэтому назовите мой код мусором или как угодно :) Я просто хочу кое-что узнать.

P.S. Прошу прощения за мой плохой английский:)

Answer 1

MVC - интересная абстракция, но есть некоторые проблемы.

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

Лучшее описание, которое я видел относительно Java, это то, что представление - это ваши компоненты Swing, поэтому ваша часть кода представления - это не что иное, как размещение этих компонентов на экране.

Ваш контроллер - это остальная часть этого класса, слушатели и остальная часть вашего кода, который взаимодействует с представлением.

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

EDIT / Дополнительно: Я использовал шаблон, в котором контроллер и представление изолированы, и он более гибок, но это, как правило, требует гораздо больше работы. Я думаю, что Struts использует модель привязки - если вы хотите увидеть некоторые приемы абстракции, вы можете посмотреть там или поискать материал о «связывании» элементов управления свингом.

Answer 2

Я не думаю, что эта диаграмма очень хорошая и, вероятно, делает вещи намного более запутанными.

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

Таким образом, представлению нужно только знать, как отобразить / представить модель пользователю. Таким образом, любые операции над Моделью, например saveFavoriteContactsToLocalStorage(), должны быть методами Контроллера, а не класса View. Кроме того, Контроллеру не нужно ссылаться на конструируемое представление - я думаю, что в итоге происходит обратное изменение предполагаемого порядка всего шаблона MVC.

Answer 3

Я согласен с Биллом К. Стандарт MVC не так важен при работе с богатым клиентом. Это отличная модель при написании веб-приложений, поскольку события (клики в вашем браузере) сильно отличаются от вашего представления (рендеринг HTML).

Со стандартным графическим интерфейсом лучше модель называется PAC (представление / абстракция / управление). Здесь презентация (представление + обработчик событий), контроллер управляет обменами между презентацией и абстракцией. А абстракция - это ваша бизнес-модель.

Таким образом, у вас есть контроллер, который управляет связью между частью графического интерфейса пользователя (представление + пользовательские события) и вашей абстракцией. У вас есть агент PAC для любой части GUI, которую вы разрабатываете, и четкое разделение между ними.

Еще одна статья о чем-то лучше MVC, связанная с PAC: HMVC . Довольно старый, но он практичен и помогает понять вещи.

Answer 4

С моей точки зрения, это то, с чем я столкнулся, когда впервые попытался разделить свои Модели, Представления и Контроллеры в моем первом настольном приложении.

В веб-приложениях шаблон MVC подходит ОЧЕНЬ естественным образом из-за врожденной природы Интернета, но, к сожалению, невозможно установить чистый шаблон MVC для настольного приложения, где операционная система играет врожденную роль в уведомлениях. Обычно это приводит к тому, что шаблон реализуется так, как показано на диаграмме.

Однако шаблон, который вы показали, действительно должен быть реализован следующим образом, я думаю (я перешел на .NET после краткого знакомства с Java, поэтому, пожалуйста, имейте это в виду):

public class ContactManagerMainScreenModel
{
    ContactManagerMainScreen v;
    // Loading Local Storage
    LocalContactStorage LocalContactStorage = new LocalContactStorage();
    // Favorite list
    boolean showFavoritesList = true;

    public void register(ContactManagerMainScreen v)
    {
        this.v = v;
    }

    public void ShowOrHideFavoritesList()
    {
        if(showFavoritesList) 
        {
            showFavoritesList = false;
            v.RefreshView(this);
        }
        else
        {
            showFavoritesList = true;
            v.RefreshView(this);
        }
    }
}

Между тем, контроллер будет отвечать за получение действий пользователя. Поэтому, если у вас есть кнопка с надписью «Переключить избранное», это заставит контроллер вызвать _model.ShowOrHideFovingList (). Модель обновится сама и попросит представление обновить себя, используя ее новое состояние.

Теперь представление не будет зависеть от контроллера.