ASP.NET User Controls that communicate directly with Service Layer?

views:

answers:

+2 Q:

ASP.NET User Controls that communicate directly with Service Layer?

Is it considered poor design to create "black box" User Controls that communicate directly with the service layer (to perform CRUD operations, validation, etc)?

By "black box", I mean that they retrieve/persist data independently of the page they are hosted on (using IoC injected services). Each UC can be dropped onto a page and it will just work. Mind you, there is no business logic embedded in any of these UCs whatsoever (that's all in the Domain layer).

This approach was driven by two factors:

Our application has many pages that are essentially variants on the same view (with slightly different layouts).
Furthermore, our UI designer is fond of allowing discrete parts of a page to be opened up for editing. Click here for a poor attempt at illustrating this concept.

Anyway, it felt like giving the UCs the ability/responsibility to render and persist themselves would do away with quite a bit of code duplication.

If this approach is indeed considered "icky", please feel free to suggest an alternate one that is more appealing (perhaps MVP?) I'm stuck with WebForms for the foreseeable future.

Thanks!

+1 A:

Assuming you correctly implement the MVP pattern for each control in this fashion this is perfectly acceptable IMO.

Personally the way I have solved issues like this is allowing my MVP pattern to have hybrid view presenters that can access many views (think IListView, IEditView) however this would be more problematic to do if they're truly user controls since they half exist outside of the page to start with. If they're user controls with their own tags you can either implement it the way you asked in your quesiton or you need to expose all the possible events to implement the code on your pages.

Chris Marisic 2010-03-01 20:08:44

Unfortunately, I haven't implemented these User Controls using MVP, although I have long considered re-writing them as such. I just read your blog post on "Creating a generic Model-View-Presenter framework" (good stuff, btw) and I'm trying to figure out if I can apply the same basic MVP pattern to a User Control. Comments?

Dirk 2010-03-01 21:38:09

Yes you should be able to implement them in a similar way. I am going to have a new blog post about the MVP pattern and how the view can be decoupled from the presenter in ASP.NET taking advantage of the CurrentHandler to dynamically resolve the view (i'm not sure if you can do this in a user control you'll have to test it) but you should check out http://stackoverflow.com/questions/1373750/asp-net-basepage-back-referencing-to-concrete-implementation this shows a way you can trick the compiler into letting you cast this to your View correctly which should be applicable to a user control also.

Chris Marisic 2010-03-01 23:16:14

Well make the view loosely coupled and not as strongly coupled as the standard implementation of using the setter for the Presenter to join the View to the presenter.

Chris Marisic 2010-03-01 23:18:53

+1 A:

No, this is actually how one goes about doing good SOA, where you have "stacks" that are relatively tightly coupled horizontally, loosely coupled with other "stacks" of functionality. The stacks are tied from the UI down to the persistence layer. Think how Amazon and EBay have pages, each page is a composite UI, each piece of the UI is independent of the other pieces, but within each piece the layers are dependent upon one another.

David 2010-03-01 20:30:16

ansaurus

tags:

views:

answers:

ASP.NET User Controls that communicate directly with Service Layer?

related questions