Инжекция предъявителя в шаблоне Образцового Предъявителя Представления с StructureMap
Проблема:
Вы возвращаете модель как объект типа MBilling, но используете ее как IEnumerable<MBilling> в представлении.
Решение:
Вам не нужно IEnumerable<T> здесь, так как оно не перечисляемо . Так что убери его и просто сделай:
@model Shop.Models.MBilling
4 ответа
Я Использовал бы решение # 1b и создал бы супертип слоя для всех страниц, чтобы к DRY инициализация предъявителя немного больше. как это:
Код страницы:
public partial class _Default : AbstractPage, IEmployeeView
{
private EmployeePresenter presenter;
private EmployeePresenter Presenter
{
set
{
presenter = value;
presenter.View = this;
}
}
protected override void Do_Load(object sender, EventArgs args)
{
//do "on load" stuff
}
}
Код Виртуальной страницы:
public abstract class AbstractPage : Page
{
protected void Page_Load(object sender, EventArgs e)
{
ObjectFactory.BuildUp(this);
this.Do_Load(sender,e);
//template method, to enable subclasses to mimic "Page_load" event
}
//Default Implementation (do nothing)
protected virtual void Do_Load(object sender, EventArgs e){}
}
С этим решением у Вас есть инициализация предъявителя (созданный ObjectFactory) в одном классе только, если необходимо изменить его позже, можно сделать это легко.
Править:
Do_Load должен быть абстрактным или виртуальным?
Шаблонный Метод первоначально указывает, что метод должен быть Абстрактным, чтобы вынудить подклассы реализовать его, придерживаясь контракта суперкласса. (см. пример Википедии "Монополии" <"Игра").
С другой стороны, в данном случае мы не хотим вынуждать пользовательский класс переопределить наш метод, но дать ему шанс сделать так. Если Вы объявите это абстрактный, то много классов будут обязаны переопределить метод только для отъезда этого пустым (это - ясно запах кода). Таким образом, мы обеспечиваем, разумное значение по умолчанию (ничего не сделайте), и сделайте метод виртуальным.
Спасибо всем за Ваш очень ценный вклад. Ваши ответы, которые каждый дал мне ценные идеи объединить вместе в моем конечном решении и это - то, что я придумал:
public abstract class ViewBasePage<TPresenter, TView> :
Page where TPresenter : Presenter<TView>
{
protected TPresenter _presenter;
public TPresenter Presenter
{
set
{
_presenter = value;
_presenter.View = GetView();
}
}
/// <summary>
/// Gets the view. This will get the page during the ASP.NET
/// life cycle where the physical page inherits the view
/// </summary>
/// <returns></returns>
private static TView GetView()
{
return (TView) HttpContext.Current.Handler;
}
protected override void OnPreInit(EventArgs e)
{
ObjectFactory.BuildUp(this);
base.OnPreInit(e);
}
}
И наследованный моей исходной страницей:
public partial class _Default :
ViewBasePage<EmployeePresenter, IEmployeeView>, IEmployeeView
{
protected void Page_Load(object sender, EventArgs e)
{
if (!Page.IsPostBack)
{
_presenter.OnViewInitialized();
}
_presenter.OnViewLoaded();
Page.DataBind();
}
#region Implementation of IEmployeeView
...
#endregion
}
Я использовал класс базовой страницы с:
protected override void OnInit(EventArgs e)
{
StructureMap.ObjectFactory.BuildUp(this);
base.OnInit(e);
}
Подход базового класса работает над пользовательскими элементами управления также, которые один сохранили меня от модуля (не хотел иметь 2 способа настроить его). Для страницы это
public partial class Employee : View, IEmployeeView
{
public ViewPresenter Presenter { get; set; }
private void Page_Load(object sender, EventArgs e){}
}
Я ввожу представление через конструктора. Для предотвращения проблемы циклической ссылки о конфигурации structuremap просто используйте этот вспомогательный метод:
static T GetView<T>()
{
return (T) HttpContext.Current.Handler;
}
На structuremap конфигурация используют конвенцию и для предъявителя и для инжекции представления.
Я создал свою собственную платформу MVP как этот также. Я нашел, что лучший способ для меня состоял в том, чтобы использовать дженерики с классом базовой страницы. Путем определения Предъявителя вводят в универсальном определении класса, я добираюсь для пропущения большей части кода, которого требует каждое из предложений.
Однако существуют некоторые вещи, мне не нравится приблизительно делать его тот путь. Определение класса может закончить тем, что выглядело скорее сложным и не легко читать для новичка. Я также не полностью разработал хороший способ использовать модель событий в базовой странице.
Извините у меня нет кода для Вас здесь, но я могу отправить некоторых для Вас, если Вы желаете. У меня также есть старая версия кода, отправленного по www.codeplex.com/aspnetmvp, должны Вы хотеть видеть, как он работает.