You are wondering whether master pages are a good solution in ASP.NET. The author thinks master pages are a needlessly confusing and slow solution to a problem that confounds object-oriented programming and inheritance. Here we look at why the author thinks master pages are not an ideal solution in many cases.
We will start with one of the biggest master page problems: the performance problems. Having a master page will result in another assembly in your project in many settings. This is an extra burden, and in the author's experience removing master pages has resulted in better performance.
Master pages are confusing because they do not inherit as you might think they should. For a content page to access object data based on the master page, it must take a confusing route and use Master.Page.FindControls(). Here's some code that shows how to change the value of a TextBox when using a master page.
// How content page can change TextBox.
TextBox mpTextBox = mpContentPlaceHolder.FindControl("TextBox1") as TextBox;
if (mpTextBox != null)
{
mpTextBox.Text = "TextBox found!";
}
Alternative without master pages. Why do we need to use FindControl here? Because the content page is a sibling, not a child of the master page. It cannot access the control directly. Here's how you could do it in the same page.
// How regular page can change TextBox. TextBox1.Text = "TextBox found";
Perhaps the biggest advantage of Visual Studio is that it has a powerful programming "helper" that tells you whether something exists and what it is. In the second example above, IntelliSense will work and tell you that the TextBox exists. In content pages, it will not.
You want to have a site-wide caching scheme, but master pages will not let you specify it there. You must change the cache settings of each content page separately. If you have few pages, this is fine, but it becomes less practical as your site grows.
<%-- Can't put on master page. --%>
<%@ OutputCache Duration="600" VaryByParam="file" %>
A good use of a content page that uses a master page is to have one for the "contact us" or "about us" page. However, if your business grows a lot, you might need ten contact pages. You then have 10 more source files, and many more files to compile.
Content versus code. This is the most severe drawback of master pages. If a website has any significant data, it must enforce a clear separation between data and code. Content pages allow embedded code in data. The result is a site that works but is needlessly slow and complicated. It's better to consolidate your logic together, and separate your data.
Data separation. Master pages do work better with fewer content pages. However, the whole point of content pages is to have content. They also always allow code, which confounds the programming model of content/code separation. You could more easily avoid the master page, and use logic to change parts of the page.
Here we looked at some drawbacks of master pages in the ASP.NET web framework. The author's opinion is that it is better to eliminate master pages for less confusion, better performance, and a clearer separation of code and data. This will result in fewer files to compile and fewer assemblies with easier deployment. You site can adhere to the object-oriented inheritance model instead.