Разделение представления, представления и веб-форм ASP.NET - PullRequest
Новая
       30

Разделение представления, представления и веб-форм ASP.NET

6 голосов
/ 05 апреля 2010

У меня есть страница веб-форм ASP.NET, которую докладчик должен заполнить элементами управления. Это взаимодействие несколько чувствительно к жизненному циклу страницы, и мне было интересно, есть ли в этом хитрость, о которой я не знаю.

Я хочу быть практичным во всем, но не проверять компромисс.

В настоящее время у меня есть это: 

public interface ISomeContract
{
    void InstantiateIn(System.Web.UI.Control container); 
}

Этот контракт зависит от System.Web.UI.Control, и мне нужно, чтобы он мог что-то делать с помощью модели программирования ASP.NET Web Forms. Но ни представление, ни докладчик могут не знать об элементах управления сервером ASP.NET.

Как мне обойти это? Как я могу работать с моделью программирования ASP.NET Web Forms в моих конкретных представлениях, не принимая зависимость System.Web.UI.Control в моих контрактных сборках?

Чтобы прояснить ситуацию немного, этот тип интерфейса полностью связан с композицией пользовательского интерфейса (с использованием MEF). Он известен всему фреймворку, но на самом деле он вызывается только из конкретного представления. Конкретное представление по-прежнему является единственным, что известно о веб-формах ASP.NET. Однако те публичные методы, которые говорят, что InstantiateIn(System.Web.UI.Control) существуют в моих контрактных сборках, и это подразумевает зависимость от ASP.NET Web Forms.

Я думал о каком-то механизме двойной отправки или даже шаблоне посетителей, чтобы попытаться обойти это, но я пока не знаю, в каком направлении я хочу идти, и мне действительно хотелось бы получить какую-то информацию по этому вопросу.

Ответы [ 4 ]

2 голосов
/ 12 апреля 2010

Не уверен, как посетитель решит проблему. Но почему ваши контракты не выглядят так: 

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.

0 голосов
/ 08 апреля 2010

Я читал о гибких методах, tdd, модульном тестировании, надежных шаблонах проектирования и чувствовал себя совершенно бессильным преодолеть разрыв между всей этой замечательной теорией и веб-формами asp.net.

У меня был другой способ попытаться найти решение этой проблемы ранее сегодня, и нашел эту статью:

Это отрывок из книги, которая, как я думал, решит все мои проблемы, но эта глава на самом деле является просто введением в возможности реализации шаблона MVP в веб-формах, и в заключение он говорит, что это не очень практично. Остальная часть книги посвящена тестированию asp.net MVC, насколько я понял.

Существует также новый проект, цель которого - вернуть любовь на платформу вебформ:

0 голосов
/ 08 апреля 2010

В «обычных» веб-формах ASP.NET ваш элемент управления страницы / пользователя технически «отвечает» за обработку и накладывает свой жизненный цикл на код. Страница - это ведущий и вид, нравится вам это или нет.

Большинство попыток реализовать шаблон MVP в этой среде просто добавляют излишнюю сложность в и без того слишком сложную среду! Притворяться, что другой класс - это Ведущий, это просто ... притворяться. (На веб-сайтах MVC Контроллер действительно контролирует код, а View - нет, поэтому этот аргумент больше не применяется.)

Моя рекомендация - позволить представлению следить за своим жизненным циклом и вызывать классы репозитория и модели для извлечения / сохранения данных и вызова команд.

При таком подходе классам Model не нужно ничего знать о System.Web. Эти те же классы модели могут затем использоваться на будущих веб-сайтах MVC, или Silverlight, или в качестве веб-службы для приложений WPF, или встраиваться в приложение WPF и т. Д. Решение о том, как реализовать (с помощью элементов управления), зависит от View ответ / данные, полученные от модели.

Классы Model можно тестировать сколько угодно, если вы правильно настроите их для поддержки внедрения зависимостей.

Надеюсь, это поможет!

0 голосов
/ 07 апреля 2010

Один из способов, которым вы можете отделить свой контракт от вашего веб-элемента управления, - это иметь отдельную программу записи, которая обрабатывает получение информации из ISomeContract и помещает ее в ваш контейнер Control. Это может находиться в сборке, которая ссылается как на сборку по контракту, так и на System.Web.

...