views:

1292

answers:

2

In an asp.net application, I would like to combine the use of the Webclient Software Factory (WCSF), and its associated Model View Presenter pattern (MVP), with Page Method, that is static methods on the .aspx Views marked with the [WebMethod] attribute.

However, static methods on the aspx page would seem to break the Model View Presenter pattern since an instance method is required on the page to have the context of the Presenter and Controller necessary for the View to talk to.

How would one extended asp .net's MVP pattern in WCSF to support [WebMethods] on the page, aka the View?

+2  A: 

I think you could come close to what you are looking for by using an ASP.Net AJAX Web Service instead of static page methods. The web service has the advantage of not being static, and depending on how your views are implemented, (I'm not familiar with the specifics of the WCSF MVP pattern) you could potentially make the web service your "View" layer..or at least something fairly close.

I've done something similar in a project I'm working on. I ended up needing to create a thin data-only class which got serialized to JSON by the web service to carry the data from the model to the "view", but the web service had essentially the same methods that would be exposed as events on the view.

One of the things I liked about this approach is that all the bits, including the web service, are testable.

ckramer
+3  A: 

I had a similar problem recently when doing a MVP patterened project and wanting a lot of AJAX integration. You're best off having web services which conform to the MVP pattern that you call.

Keep in mind that a PageMethod is little more than a web service, just in the current page. It doesn't have access to any page-level objects so the advantages of having it there are minimal. I actually think they are disadvantagious, they give developers (who are unfamiliar with the concept) the idea that they can interact with page-level objects.

The flip-side of the coin is what your PageMethod is doing, if your page method is not needing to interact with the Model (say, it's handling complex arithmatic calculations which are faster in C#/VB.NET than JS) then the operation is really a UI level operation and quite probably irrelivant if you were to turn the app into a WinForm (or something else).

Keep in mind that all interaction with data at a UI level is specific for that UI implementation. If you were to write a different UI for the presenters then chances are you'll have different UI level data interaction.

Slace
I like your explanation of the benefits and drawbacks of Page Methods and the comparison to web services. I want to see if anyone else comments.
eniac
So I can integrate web services instead of page methods, but I think I fail to see where web service calls fit into the MVP pattern. What criteria should determine when the view, that is the page on the browser, make a call to the data service as an asynchronous request to a web service?
eniac
It fits in because the reason you need the web service is to do UI level operations. Each UI implementation will have different ways to handle the operation, a webform uses web services, a winform may have a windows service or something else
Slace