ASP.NET User Controls, которые взаимодействуют напрямую с сервисным уровнем? - PullRequest
Новая
       31

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

2 голосов
/ 01 марта 2010

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

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

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

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

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

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

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

Спасибо!

Ответы [ 2 ]

2 голосов
/ 01 марта 2010

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

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

1 голос
/ 01 марта 2010

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

...