Master and Base pages

[jshurst]

Should I use a Master page as a base page as well? What I mean is if I'm interested in having a base page, should I just inherit the code behind of my other pages from my master page instead of having a master and a base page?

How do you guys usually do it? Do you create a new web form and just give it a name of MyBasePage.aspx, or just create a class for it (MyBasePageClass.vb)?

Any advice would be appreciated.

 

[ca8msm]

I usually used base pages in version 1 of the framework but since Master Pages were introduced in version 2, personally I just add the relevant code to the Master Page rather than a base class and just use that Master for each page.

Depending on what you need to do, you could also create a base class for each MAster Page to inherit but in most cases that will be overkill.


____________________________________________________________

Need help finding an answer?

Try the Search Facility or read FAQ222-2244 on how to get better results.

 

[BoulderBum]

There's a principle in object oriented programming that states we should "favor composition over inheritance". The reason being is that the system usually becomes more flexible, especially in languages (like .NET languages) that allow for only single inheritance.

What that means in regard to your question in practical terms is that putting logic in your MasterPage is a more compositional and thus flexible approach.

For instance, if you have several pages sharing important functionality through a common base class, but then have a situation where the application merges with another system which uses completely seperate base page classes (which also have important functionality), then you're in trouble! Page's can't inherit from more than one class, so all of a sudden it become very awkward maintain.

Contrast this with a system where much of the functionality comes from a MasterPage you can configure any page to use. In that situation, it's quite easy to introduce your important functionality when you merge different systems' pages: you just have them use the same MasterPage and you don't care what base page class they inherit from (because your system doesn't rely on inheritance).

I actually speak from experience on this one because we too relied on Page inheritance for functionality in one of my old apps. It worked well at first, but as the system grew and we needed different types of pages (while sharing some similar functionality), the situation got pretty ugly.

 

[jshurst]

So I'm guessing that System.Web.UI.MasterPage inherits from System.Web.UI.Page ? Because that is what the master page inherits from. Furthermore if I do try to inhert my page from the master page then it gives me an error on the page declaration stating that if I want to overload the base method then the base class must be declared 'Overloads.'

I know that I can declare a new instance of my master page and then use the properties, but is this the way you guys do it (or maybe just use 'Shared')?

BoulderBum:

You said...

Contrast this with a system where much of the functionality comes from a MasterPage you can configure any page to use. In that situation, it's quite easy to introduce your important functionality when you merge different systems' pages: you just have them use the same MasterPage and you don't care what base page class they inherit from (because your system doesn't rely on inheritance).

Can pages use more than one masterpage? If not then what is the difference in just adding all of the code to a base page class and using that one, seems like it would be the same thing?

 

[jshurst]

Thanks for the info guys. I think I'm at the point where I need to start reading some best-practices books/papers.

Can someone tell me what they would do in this scenario: Let's say you have the need to log errors for every Try/Catch block. In the last project I did I created a class "ErrorLogger" and called that from a function in my base page. Then all of my pages inherited from the base page and I only needed to call my base page function (which called the ErrorLogger" class). Is this not good practice? Seems to be the easiest way, rather than referencing the Errorlogger class in every page, but what is the correct way?

Thanks,

J

 

[BoulderBum]

I believe MasterPages actually inherit from UserControl.

Can pages use more than one masterpage? If not then what is the difference in just adding all of the code to a base page class and using that one, seems like it would be the same thing?

The difference is that with the MasterPage, you encapsulate logic into a container that can be plugged into Pages and swapped out at will. In OO, this is known as "loose coupling".

To elaborate on my previous example, let's say you have 20 page with an inheritance setup like this:

[tt]
Page Count Base Class
----------------------------------
5 System.Web.UI.Page
10 MyCustomPage
5 AnotherCustomPage
[/tt]

Let's say that on load, you want all pages to perform some initialization logic, security checks, whatever. Let's also say that you put this logic into MyCustomPage.OnLoad() and that some logic contained in MyCustomPage should only apply to pages of type MyCustomPage. If you want the other pages of the system to share some of the functionality of MyCustomPage, then you might be able to do it with the pages that inherit from System.Web.UI.Page (by chaning their superclass), but that would introduce uneeded functionality that only applies to MyCustomPage, and what about the pages inheriting from AnotherCustomPage?

Let's further assume that AnotherCustomPage also has important logic, but it's logic that should only apply to pages of type AnotherCustomPage and that AnotherCustomPage is a class you bought as part of a software package from a third-party vendor. So how do you share all the functionality of MyCustomPage?

With inheritance, it's not possible. You don't have access to the source code, so you can't change the superclass, and even if you did, you'd lose the functionality of AnotherCustomPage.

So how do you solve the problem of sharing only the needed functionality, and sharing it across pages? You do it with composition! If you have a component existing outside of the page class that does all of the processing, then you can easily include that component in all twenty pages.

In this case, we're speaking of a MasterPage as the component, because you can easily configure each page to use the MasterPage, and it would perform the common logic without obtruding into the inheritance structure.

So you get a sense that it's a step in the right direction, but your question is still valid, "What if we have more than one MasterPage introducing important functionality?".

In that case, you'd further abstract the functionality into its own class so that several MasterPages can use it which would actually be more "ideal" from an OO perspective. The introduction of composition of MasterPages is superior to an inheritance chain in terms of OO, but it's not a perfect solution.

In the last project I did I created a class "ErrorLogger" and called that from a function in my base page. Then all of my pages inherited from the base page and I only needed to call my base page function (which called the ErrorLogger" class). Is this not good practice?

The ErrorLogger is a good idea because it encapsulates logging functionality (though you can also consider TraceListeners), but if it works with your design, the Application_Error of Global.asax would be a "looser coupled" location to handle and log errors (because, again, you drop the dependency on a page type which could prove problematic to maintainability).

Alternately, you can consider exposing the logging functinoality as a static method so the worst you'd have to do is call ErrorLogger.LogException( myException ).