page controller without inheritance

[Andy Fish]

Hi,

I have been thinking about the design of a large ASP.NET app and I've read
people have a lot of trouble implementing front controller, especially with
postbacks, so I don't feel comfortable going down that route at the moment.

The main proplem with the page controller pattern seeems to be related to
the fact that inheritance is used to implement different types of behaviour
and this will lead to large complex class hierarchies. However, I don't
really see why this needs to be the case.

My proposal is to create a single abstract subclass of System.Web.UI.Page
(from which all web pages would inherit) that overrides stuff like Page_Load
and delegates all controller-related responsibilities to a helper object.
This could call back into the page where necessary, and the callbacks could
be implemented by the page itself or the abstract page controller.

the class of the helper object could be specified once (in the constructor
of the actual page), but this would be the only place where every page has
to be edited to comply with the framework. The helper objects themselves
could have any arbitrary class hierarchy (or different class hierarchies as
long as they implement a standard interface)

I haven't started work in earnest on this yet, but I would be interested in
an thoughts on this idea. Does it go any way to solving the problem? is
there really a problem in the first place? is front controller really quite
easy after all? is page controller a lost cause?

Andy

 

[bruce barker]

I use the page controller pattern. You are correct, you should create your
own base page. I also created all my own web controls to standardize the
messaging to the helper objects. While the startup cost is higher for the
first page, adding pages is simple.

-- bruce (sqlwork.com)