Following a software design pattern is good. Falling into a software anti-pattern is bad.
The “master” in “master page” can be misleading. The term suggests the master page is somehow in control of everything happening during the lifecycle of a request. What actually happens is that the master page injects itself into the Controls collection of a web form and becomes a child control, (see figure 7 of Fritz Onion’s article on the topic). The master becomes the child.
Because the master page sounds like it commands all that happens under it’s domain, there is a tendency to lean towards a God object anti-pattern design. In other words, the master page class knows too much, and does too much. If you see a web form calling into a master page method to open a database connection or authenticate a user, then you are witnessing the master page anti-pattern in full glory.
Master pages are for UI layout, nothing more.
Comments
I think Scott Guthrie's team should have named this feature something else (Page Template Control?) and made it very clear what the limitations are. I can see a lot of new ASP.NET 2.0 developers spending hours trying to get content page code to run properly in the Master's code behind. My background is BizTalk & C#, not ASP.NET and I'm certainly glad I asked the question before spending a lot of time playing with this.
Thanks again for the advice!
Jeff
They had misunderstood my suggestion to use the Master Page approach. I helped them refactor it to use the whidbey approach.