OdeToCode IC Logo

The Promise of Partial Classes and ASP.NET

Friday, April 21, 2006

Web site projects in Visual Studio 2005 give us exactly one code-beside file per web form. We specify the name of the file with the CodeFile attribute in the form’s @ Page directive. There can be no other file – a web form and its code-beside file maintain a monogamous relationship.

But wait! Partial classes in C# and Visual Basic say I can:

“…split the definition of a class or a struct, or an interface over two or more source files. Each source file contains a section of the class definition, and all parts are combined when the application is compiled.”

True, true, but there is no capability to specify multiple files with the CodeFile attribute, and the CodeFile attribute is the only piece of information the ASP.NET runtime has available to know what else it needs to compile with the web form (each web form can compile into a distinct assembly). I can’t drop a partial class definition for the web form into App_Code, either, because App_Code compiles into a separate assembly, and partial class definitions cannot span multiple assemblies.

Let’s approach the problem from a different angle: why would we want a web form’s code-behind to span multiple files? Is the class hard to manage because it has too much code inside? That scenario sounds like an architectural problem that can’t be solved with the partial keyword. Do we want to cleanly separate event handlers from virtual overrides? Perhaps a #region would do a better job.

Web Application Projects are a different matter. WAP allows multiple partial class definitions. In fact, WAP itself will create two source code files for each web form. One file is for human generated code, and the other file is for designer generated code. This scenario is an ideal candidate for partial classes. With WAP, Visual Studio compiles all of the .cs/.vb code-behind files at once, and into a single assembly. WAP allows the compiler to merge partial class definitions.

Luca Friday, April 21, 2006
That's the same concern I thought some day ago.

I'd like to extend some behavior of the base page class and I'd like to provide it at design time through the use of the build providers.
Using the web site way, due to the fact of the different assembly generated for app_code, there's no way to do that.

With WAP, all code in the web site will be part of the same assembly ? That's another reason to come back to the nice and old web application project :)

Scott Friday, April 21, 2006
Yes, with WAP all the code compiles into the same assembly.
Milan Negovan Monday, April 24, 2006
I'll take WAP over web site projects any day of the week. I simply don't understand the idea of putting BL, DAL, etc, in a folder within a web project. So much for separation of concerns.

Look at the Time Tracker Starter Kit, for example. They have one huge code file for all database access in the likes of a provider. It's impossible to navigate around it and find anything there. A partial class would allow to split it into manageable chunks. But, and I agree with you, something of this size is an architectural problem.
Rick Strahl Wednesday, May 3, 2006
Milan, while I agree about WAP, there's nothing in stock projects that forces you to do any thing different about DAL, BL projects. You can separate away the same way you can in WAP.

The big problem with stock projects is the hack in which the classes are compiled and complicate any and all issues related to cross referencing pages and controls, and using control or page level inheritance at the project level.

Partial classes have really nothing to do with these problems - its the compilation model that compiles to multiple assemblies that's at issue.

WAP throws out all that non-sense and returns a predictable compilation model, IMHO.
Comments are closed.