Пользовательские элементы управления ASP.NET, которые напрямую взаимодействуют с сервисным уровнем?

Считается ли плохим дизайном создание пользовательских элементов управления «черного ящика», которые напрямую взаимодействуют с сервисным уровнем (для выполнения операций CRUD, проверки и т. д.)?

Под «черным ящиком» я подразумеваю, что они извлекают/сохраняют данные независимо от страницы, на которой они размещены (используя службы, внедренные IoC). Каждую UC можно перетащить на страницу, и она просто работает. Имейте в виду, что ни в один из этих UC не встроена бизнес-логика (это все на уровне предметной области).

Такой подход был обусловлен двумя факторами:

  1. В нашем приложении много страниц, которые по сути являются вариантами одного и того же вида (с немного разными макетами).

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

    В любом случае, казалось, что предоставление UC возможности/ответственности за рендеринг и сохранение самих себя избавит от дублирования кода.

Если этот подход действительно считается «неприглядным», пожалуйста, не стесняйтесь предлагать альтернативный, более привлекательный (возможно, MVP?). Я застрял с WebForms в обозримом будущем.

Спасибо!


asp.net mvp user-controls separation-of-concerns
person Mitch A    schedule 01.03.2010    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Предполагая, что вы правильно реализуете шаблон MVP для каждого элемента управления таким образом, это вполне приемлемо для IMO.

Лично я решил такие проблемы, позволив моему шаблону MVP иметь презентаторов гибридного представления, которые могут получить доступ ко многим представлениям (думаю, IListView, IEditView), однако это было бы более проблематично сделать, если они действительно являются пользовательскими элементами управления, поскольку они наполовину существуют вне страницы для начала. Если это пользовательские элементы управления со своими собственными тегами, вы можете либо реализовать их так, как вы задали в своем вопросе, либо вам нужно предоставить все возможные события для реализации кода на ваших страницах.

person Chris Marisic    schedule 01.03.2010
comment
К сожалению, я не реализовал эти пользовательские элементы управления с помощью MVP, хотя давно думал о том, чтобы переписать их как таковые. Я только что прочитал ваше сообщение в блоге о создании общей структуры Model-View-Presenter (хороший материал, кстати), и я пытаюсь выяснить, могу ли я применить тот же базовый шаблон MVP к пользовательскому элементу управления. Комментарии? - person Mitch A; 02.03.2010
comment
Да, вы должны быть в состоянии реализовать их аналогичным образом. У меня будет новый пост в блоге о шаблоне MVP и о том, как можно отделить представление от презентатора в ASP.NET, используя CurrentHandler для динамического разрешения представления (я не уверен, что вы можете сделать это в пользовательский контроль, вам придется его протестировать), но вы должны проверить stackoverflow.com/questions/1373750/ показывает, как вы можете обмануть компилятор, чтобы вы могли правильно преобразовать это в свой вид, который также должен быть применим к пользовательскому элементу управления . - person Chris Marisic; 02.03.2010
comment
Хорошо сделайте представление слабосвязанным и не столь сильно связанным, как стандартная реализация использования установщика для презентатора для присоединения представления к презентеру. - person Chris Marisic; 02.03.2010

arrow_upward
1
arrow_downward

Нет, на самом деле это то, как делают хороший SOA, когда у вас есть «стеки», которые относительно тесно связаны по горизонтали, слабо связаны с другими «стеками» функциональности. Стеки привязаны от пользовательского интерфейса к уровню сохраняемости. Подумайте, как у Amazon и EBay есть страницы, каждая страница представляет собой составной пользовательский интерфейс, каждая часть пользовательского интерфейса независима от других частей, но внутри каждой части слои зависят друг от друга.

person BlackICE    schedule 01.03.2010