Using MVP pattern in ASP.NET

[uran1]

In MVP (Model-View-Presenter) presenter shouldn;t depend on view
layer(so it cannot contain reference to System.Web)- we cannot use
Membershi and Role providers in Preseneter (Controlling layer). Access
to those objects is posible only in view, where should be no logic
(business logic).

How to solve this problem - does view should pass information about
currently logged user (using MembershipProvider to dermine who is
logged)- allow acces to these information to presenter through view
interface? Then presenter could decide whether to show or not
information and pass data to view; That aproach makes using ASP.NET
login (and other 'native' ) asp controls limited.

The similar problem is how to generate website menu- using SiteMap
based on RoleProvider (in sitemap xml we define which roles are allowed
to view which pages)m we can automaticlly hide som menu options, which
are not avaialable to currentyl logged user, by this aproach (again)
need to place some business logic in aspx file (which is in view
layer).

What is the solution , which let use use handy asp.net control?maybe
yet another pattern?

 

[msnews]

Try to get past the patterns. You should not be trying to achieve
conformance to a pattern above the actual requirements for the project. It
is good to try to create a clean separation between the data model and the
view, but your ultimate goal should be maintainable code which meets your
requirements.

And if you are using the databound controls in ASP.NET you generally have a
good separation. You can choose to bind the controls to a SqlDatasource
with inline SQL, but I feel that can be brittle for any application which be
modified many times over time. And pretty all software will change unless
you throw it away right after using it once.

Perhaps a more stable approach is to instead reference a set of stored
procedures or perhaps create a custom DataObject populated with an
ObjectDataSource.

But never get caught up on what pattern matches your design. Let the
patterns emerge as you carefully construct the code.

Brennan Stehling
http://brennan.ofwhite.net/blog/