Отделяя представление, презентацию и Веб-формы ASP.NET
У меня есть страница ASP.NET Web Forms, которую предъявитель должен заполнить со средствами управления. Это взаимодействие несколько чувствительно к жизненному циклу страницы, и я задавался вопросом, существует ли прием к нему, о котором я не знаю.
Я хочу быть практичным обо всем этом, но не тестируемости компромисса.
В настоящее время у меня есть это:
public interface ISomeContract
{
void InstantiateIn(System.Web.UI.Control container);
}
Этот контракт имеет зависимость от Системы. Сеть. UI.Control и мне нужно это, чтобы смочь сделать вещи с моделью программирования Веб-форм ASP.NET. Но ни у представления, ни предъявителя не может быть знания об управлении сервером ASP.NET.
Как я обхожу это? Как я могу работать с моделью программирования Веб-форм ASP.NET в своих конкретных представлениях, не беря Систему. Сеть. Зависимость UI.Control в моих блоках контракта?
Для разъяснения вещей немного этот тип интерфейса - все о составе UI (использующий MEF). Это известно всюду по платформе, но это действительно только называют из конкретного представления. Конкретное представление является все еще единственной вещью, которая знает о Веб-формах ASP.NET. Однако те открытые методы, которые говорят InstantiateIn(System.Web.UI.Control) существует в моих блоках контракта, и это подразумевает зависимость от Веб-форм ASP.NET.
Я думал о некотором двойном механизме отправки или даже шаблоне "посетитель", чтобы попытаться работать вокруг этого, но я еще не знаю, в котором направлении я хочу пойти, и я действительно хотел бы некоторый вход по вопросу.
4 ответа
Один из способов отделения контракта от веб-элемента управления - создание отдельного модуля записи, который обрабатывает получение информации из ISomeContract и помещает ее в контейнер Control. Он может находиться в сборке, которая ссылается как на сборку контракта, так и на System.Web.
В «обычных» веб-формах ASP.NET ваша страница / пользовательский элемент управления технически «отвечает» за обработку и накладывает свой жизненный цикл на код. Страница - это Presenter и View, нравится вам это или нет.
Большинство попыток реализовать шаблон MVP в этой среде просто добавляют лишнюю сложность и без того слишком сложной среде! Притворяться, что ведущим является другой класс, - это просто ... притворство. (На веб-сайтах MVC контроллер действительно управляет кодом, а представление - нет, поэтому этот аргумент больше не применяется.)
Моя рекомендация - позволить представлению следить за своим собственным жизненным циклом и позволить ему вызывать Репозитории и классы моделей для извлечения / сохранения данных и вызова команд.
При таком подходе классам Model не нужно ничего знать о System.Web. Эти же классы модели затем можно будет использовать на будущих веб-сайтах MVC или Silverlight, или как веб-службу для приложений WPF, или встроить в приложение WPF и т. Д. Решение о том, как реализовать (с использованием элементов управления), зависит от представления. ответ / данные, которые он получает от Модели.
Классы модели можно тестировать сколько угодно, если вы правильно настроили их для поддержки внедрения зависимостей.
Надеюсь, это поможет!
Я читал о методах agile, tdd, модульном тестировании, solid, паттернах проектирования и чувствовал себя совершенно бессильным перекинуть мост от всей этой замечательной теории к asp.net webforms.
Сегодня я снова попытался найти решение этой проблемы и нашел эту статью:
Это отрывок из книги, которая, как я думал, решит все мои проблемы, но эта глава на самом деле просто введение в возможности реализации паттерна MVP в webforms, и в конце говорится, что это не совсем практично. Остальная часть книги посвящена тестированию asp.net MVC, насколько я понял.
Существует также новый проект, цель которого - вернуть любовь к платформе webforms:
Не знаю, как посетитель решит проблему. Но почему бы не сделать так, чтобы ваши контракты выглядели так:
public interface ISomeContract
{
void InstantiateIn(IControl container);
}
с реализацией IControl, возможно, в другой сборке, чтобы ваша сборка контракта была чистой, которая оборачивается поверх ASP.NET System.Web.Control, например:
public class AspnetControl : IControl
{
public AspnetControl(System.Web.Control control) { }
// IControl members that dispatch to control
}
Хотя существует высокая вероятность того, что в конечном итоге IControl в конечном итоге будет очень похож на System.Web.Control (и, следовательно, избавится от необходимости абстрагироваться от него в первую очередь), его все равно можно будет проверить, и ваше мнение и докладчики не будут иметь знать кое-что об ASP.NET.