MVP: другие параметры конструктора, кроме вида и модели? - PullRequest
2 голосов
/ 14 июля 2009

Я экспериментирую с реализацией облегченного фреймворка mvp с Delphi 2009.

Представления пассивны, но поддерживают привязку данных (через свойство интерфейса).

Я стою перед дилеммой: У меня есть несколько очень похожих взглядов / презентатор / модель триада, а именно:

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

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

Пока я так делаю:

  1. Создать представление
  2. Создать модель
  3. Создание презентатора, внедрение модели и вида в конструкторе

На самом деле передо мной стоит выбор:

  1. Имея несколько очень общих представлений / презентаторов, используйте их таким образом, но добавьте 1 или 2 параметра в конструктор
  2. Наличие некоторых суперклассов Views / Presenters и вывод из них всех моих аналогичных View / Presenter и установка определенных значений в переопределенных методах.

Можете ли вы дать мне несколько советов / советов?

(извините, если я не очень ясно)

Ответы [ 3 ]

1 голос
/ 14 июля 2009

Я бы создал общий вид / презентатор с параметрами и подклассом только при необходимости.

1 голос
/ 14 июля 2009

Другой подход (и способ, которым я однажды решил эту проблему, чтобы она работала очень хорошо), состоит в том, чтобы встроить в модель универсальный интерфейс «метаданных», и представление (либо интерфейсы, либо через наследование классов) затем использует эти универсальные интерфейсы в вашем презентере. Я решил использовать наследование для моей модели и интерфейсы для моего представления (проще было наложить интерфейс на существующую форму, чем требовать наследования формы / фрейма через доску). В моем решении конструктор для презентатора принял 3 параметра: модель, вид и «имя MVP». Я использовал имя MVP для загрузки настроек, специфичных для текущего сценария.

1 голос
/ 14 июля 2009

Фред,

Я выберу 1 и 2 таким образом, чтобы иметь абстрактные представления / презентаторы, которые содержат общие поведения и создают абстрактные функции, которые могли бы быть возможными конкретными поведениями, реализованными подклассами.

например,

  public abstract class AbstractPresenter{
      // subclass will be implemented 
      public abstract void InitView(Model model, View view);
  }

и тогда у вас могут быть подклассы, OrderFormPresenter и CustomerFormPresneter расширяются от AbstractPresenter.

public OrderFormPresenter extends AbstractPresenter{
    public void InitView(Model model, View, view){
      // do something specific values 
    }
}

public CustomerFormPresenter extends AbstractPresenter{
    public void InitView(Model model, View, view){
      // do something specific values 
    }
}

Пожалуйста, поправьте меня, если он пойдет не в том направлении. Надеюсь, это поможет.

Tiger

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...