Developing a multi-template website

Copy from: http://dotnetjunkies.com/WebLog/dotnut/archive/2005/02/10/53286.aspx
While developing a product that automates the creation of a web-site, an eCommerce one or else, you need to know that having a set of similar looking web-sites is not what your customers would want. When B uses your product to create his front-end on the web, he would want it to be different from the one A created using your product. A very simple solution to this is to use style sheet based web-pages.

But there are cases where a mere style change will not suffice. You may need to re-design the layout the pages separately, which means that you need to have multiple front end support for your business logic. This also means that if not designed properly you will end up copying calls to your “Business Logic” on every page’s code behind class; maintenance issue.

I tried this iterative design process for a while, and just wanted to validate it with you guys.

1.      Consider creating a separate object for each page. 
    The calls to a business server are made from another object. Let’s say, you are designing a Login page, in three templates. Instead of copying your calls to these three web-pages (or set of user controls if you like), delegate such calls to another class, say PoLogin. Instantiate this object in each of these 3 (or more) pages, and make a call to this method, sending it the Request. Something like this -
The PoLogin object has a
                              DataSet GetData(Request _request, <other configs/params> ) {…..}

which there page instances will call.

2.      The above design, though abstracts the calls from each page, has a flaw. There is a need to instantiate the PoLogin class in each template. So you will end up writing the instantiation code in all the pages. To refine this design, try creating a LoginBase (.aspx) page, which will instantiate the PoLogin object. Each of the template pages, will in turn extend this LoginBase page.

 A protected instance of the PoLogin class can thus be used in all the pages.

3.      This design is very good for a single web-page. Imagine having a set of 60 web-pages, each page having such a set up. This design can be further refined in such a case, bearing in mind that the Po<page> classes is basically going to fetch you data, if designed properly, with just a single method call. This leads to an easy conclusion, Factory. 
Imagine that you have 3 web-pages now, Login, Items and Categories. This will mean that you have 3 classes, PoLogin, PoItems and PoCategories which have an IPageObject contract to their instantiators. IPageObject has a single public method, with a comprehensive set of inputs that are common to all calls to get data, irrespective of the web-page in question. Instead of having each base web-page (LoginBase, ItemsBase or CategoriesBase) having the knowledge of which Page Class to instantiate, abstract this using a factory (http://www.dofactory.com/Patterns/PatternAbstract.aspx).

4.      Further refinement, the declaration of a IPageObject instance done in a PageBase class, which will be extended by all the pages

and these pages will in turn instantiate the respective Page Class using the factory.

Of course there may be better ways to do this, and I would really appreciate comments for refinement.