Шаблон MVP с помощью веб-форм и DI возражает инстанцированию
for file in *.txt
do
cat "$file"
echo
done > newfile
2 ответа
Ни класс Page, ни презентаторы не должны иметь дело непосредственно с управлением построением или жизненным циклом любой из его зависимостей - все это должно обрабатываться вашим контейнером. Поскольку внедрение конструктора не работает с WebForms, вам нужно будет предоставить все необходимые зависимости как свойства класса. Например, вы можете изменить свой класс на:
public partial class _Default : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
}
public _DefaultPresenter Presenter { get; set; }
}
Страница не должна нуждаться в какой-либо ссылке на репозиторий, поскольку она будет вставлена в ведущий.
Остальная часть этого ответа относится к StructureMap - детали могут отличаться для другие контейнеры.
Чтобы включить внедрение установщика, вам необходимо указать StructureMap, какие свойства следует заполнить. Один из способов - применить атрибут [SetterProperty] к самому свойству. Однако наличие деталей StructureMap в ваших классах может показаться немного навязчивым. Другой способ - настроить StructureMap так, чтобы он знал, какие типы свойств нужно вводить. Например:
protected void Application_Start(object sender, EventArgs e)
{
ObjectFactory.Initialize(x =>
{
x.Scan(scan =>
{
scan.TheCallingAssembly();
scan.WithDefaultConventions();
});
x.ForRequestedType<IRepository>().TheDefaultIsConcreteType<Repository>().CacheBy(InstanceScope.Hybrid);
x.SetAllProperties(set => set.WithAnyTypeFromNamespaceContainingType<IRepository>());
});
}
Метод SetAllProperties позволяет указать StructureMap, как распознавать свойства, которые он должен заполнить. В этом случае я приказываю StructureMap внедрить всех презентаторов (при условии, что все они находятся в одном пространстве имен).
Вам по-прежнему необходимо выполнять внедрение установщика для каждого запроса. В StructureMap вы используете метод BuildUp () для внедрения зависимостей в существующий экземпляр. Вы можете сделать это в событиях Init или Load каждой страницы или базового класса страницы, но, опять же, это кажется инвазивным. Чтобы полностью исключить контейнер из классов страниц, вы можете использовать событие PreRequestHandlerExecute приложения (в global.asax или IHttpModule):
protected void Application_PreRequestHandlerExecute(object sender, EventArgs e)
{
var application = (HttpApplication)sender;
var page = application.Context.CurrentHandler as Page;
if (page == null) return;
ObjectFactory.BuildUp(page);
}
Наконец, если вы хотите явно удалить свой IRepository, вы можете обработать это в событии EndRequest:
protected void Application_EndRequest(object sender, EventArgs e)
{
var disposable = ObjectFactory.GetInstance<IRepository>() as IDisposable;
if (disposable != null) disposable.Dispose();
}
Обратите внимание, что это работает правильно, потому что при инициализации мы сказали StructureMap кэшировать IRepository с помощью Hybrid, что означает «предоставить мне один и тот же экземпляр для каждого HTTP-запроса (или потока, если он не выполняется в сайт)". Когда вы извлекаете IRepository в EndRequest, вы получите тот же репозиторий, который использовался во всем запросе, и можете его удалить.
Да, стоило бы вам изучить одно из пошаговых руководств по использованию DI с ASP.NET .
Да, удаление поведения по запросу объекты в соответствующей точке обычно управляются интеграцией Контейнера с ASP.NET.
Типичная схема состоит в том, что создание объекта происходит от страницы и приложения / модуля внутрь . Обычно вы отмечаете свойства [Inject] в своем классе Page , но это зависит от того, как вы расположили свою триаду. Presenter обычно может использовать Constructo Injection, чтобы объявить, что ему нужно, независимо от того, является ли его тест или код ASP.NET. Затем во время выполнения зависимости будут удовлетворяться DI. Во время тестирования вы все еще можете использовать DI,