Я работаю над приложением, в котором используется шаблон MVP. Он все еще находится на ранней стадии разработки, поэтому я все еще могу позволить себе критически отнестись к различным вариантам дизайна.
Модель для ясности состоит из нескольких структур и некоторых API-функций, скажем, это Модель:
struct ComplexNumber {
double real;
double imag;
};
Complex_Add(ComplexNumber x, ComplexNumber y);
Complex_Mul(ComplexNumber x, ComplexNumber y);
Потом приходит вид. Я использую только примитивные типы здесь.
class IComplexView {
public:
virtual double GetReal1() = 0;
virtual double GetImag1() = 0;
virtual double GetReal2() = 0;
virtual double GetImag2() = 0;
// Setters snipped
};
Сейчас в Ведущий, насколько я мог понять, у меня было бы несколько методов для трансляции данных от модели к модели и от модели к представлению. У меня обычно есть методы ReadView () и UpdateView (). Так что эта часть докладчика будет выглядеть очень близко к этому:
class ComplexPresenter {
ICopmlexView view;
ComplexNumber x;
ComplexNumber y;
// ...
static void ReadView() {
x.real = view.GetReal1();
x.imag = view.GetImag1();
y.real = view.GetReal2();
y.imag = view.GetImag2();
}
}
UpdateView()
будет наоборот, чтобы представление заполнялось из модели.
С этой настройкой вопрос заключается в следующем:
Есть ли какой-нибудь «умный» способ связать переменную / свойство из представления с одним в модели, отличным от простого выше?
Проблема, которую я вижу в этом, заключается в относительно большом количестве добавленного кода только для перемещения данных. Сначала у нас есть предшественники в IView, а затем методы ReadView () и UpdateView (). Я думаю, что скрипт можно подключить к событию сборки и автоматически сгенерировать весь этот код, но я надеялся, что будут другие альтернативы, которые я не замечаю.
Другой подход заключается в том, чтобы просто отбросить MVP или, если быть точным, удалить докладчика и просто иметь пользовательский интерфейс<-> Логическое разделение и все тут. Очевидным недостатком является более сильное связывание, но, с другой стороны, вероятно, будет происходить заметно меньшее количество кода.
Вариант MVP, который вы описали, может быть обозначен как Passive View
— посмотри на Запись Мартина Фаулера об этом здесь. его недостаток — много шаблонного кода для синхронизации модели и вида. альтернатива с использованием некоторых data binding
механизм будет Supervising Controller
или же Presentation Model
(ака View Model
).
бросьте докладчика, и просто есть пользовательский интерфейс<-> Логическое разделение и все
одна опасность здесь заключается в том, что механизм связывания может не справиться со сложными случаями
В общем, рассмотрим эти два решения:
Presentation Model
может использовать два слоя привязок: вид-на-презентация-модель а также презентация-модель-домен-модель привязок. он поддерживает более низкую связь, но реализация этих двух механизмов сама по себе может быть утомительной.
Supervising Controller
использования вид-на-домен-модели Привязка и сама обрабатывает только сложные случаи, которые не могут быть обработаны механизмом привязки, так что вы получаете лучшее из обоих миров.
Других решений пока нет …