Мы пытаемся использовать шаблон Model-View-Presenter, используемый (практически) во всех новых разработках, которые мы предпринимаем.
Я твердо верю в то, что у меня есть фреймворк, чтобы помочь людям соответствовать требованиям дизайна, у нас есть несколько внутренних фреймворков для различных компонентов (регистрация, отправка электронной почты и т. Д.), Поэтому я пытаюсь получить некоторые вид структуры MVP разработан.
Мне удалось собрать что-то, что было бы легко использовать людям, которые не знакомы с MVP, и это не слишком далеко от того, как мы сейчас работаем . Проблема заключается в том, что он устанавливает связь между 1 представителем и 1 докладчиком.
Вот примерный план каркаса:
public abstract class Presenter<TView> where TView : IView {
public virtual T View { get; set; }
public virtual void Setup(TView view) {
this.View = view;
}
}
public interface IView { }
Основной способ, которым он работает, заключается в том, что любой созданный View наследуется от интерфейса IView и передается в класс Presenter , который наследуется от абстрактного класса Presenter.
Как вы можете видеть, я использую обобщенные элементы .NET, чтобы у разработчика была строгая типизация представления, когда они работают с докладчиком (а затем, в конечном счете, с классом, наследуемым от докладчика).
Таким образом, я могу настроить базовый компонент входа в систему следующим образом:
public class Login : Presenter<ILogin> {
public override Setup(ILogin view){
base.Setup(view);
this.View.Login += new EventHandler(login);
}
void login(object sender, EventArgs e) { ... }
}
public interface ILogin : IView {
string Username { get; set; }
string Password { get; set; }
event EventHandler Login;
}
Итак, как я сказал, мне это очень нравится, есть принудительная типизация, строго типизированные представления и шаблон MVP- , как .
Однако некоторые люди не так довольны реализацией, потому что она имеет отношение 1: 1 между докладчиками и представлениями, и, строго говоря, это не то, чем должен быть MVP.
Я сомневаюсь, насколько правдив этот аргумент на самом деле, в нескольких проектах, с которыми я тянул эту платформу (от средних до крупных), я не нашел ни одного хорошего примера, где бы я подумал: «Мне нужно иметь несколько представлений для этот ведущий ". Когда я вижу функциональность, которая может быть разделена между несколькими представлениями, я спрашиваю, должна ли она быть привязана к конкретному докладчику или должна быть в более нейтральном классе.
Не слишком ли далек от MVP фреймворк, чтобы называться MVP? Является ли необходимость иметь несколько мнений для докладчика основной целью MVP? Возможно ли даже иметь настоящую среду .NET MVP с поддержкой n-view?