Question

in a noncompiled .aspx, is it possible to have 2 partial class files for one aspx? I’m trying to do something like:

     <%@ Page          Language='C#'          inherits='_Default'          src='Default.aspx.cs'          src='Default2.aspx.cs' %> 

Both Default and Default2 have the partial class defined

Update: Yep.. It’s not compiled or the point would be moot as I’d just chuck the corresponding dll’s in the /bin directory. I need to have this not compiled because the source needs to be changed regularly. I probably could come up with a way to just update the aspx, but I’d like to not have to do that.

The reason I’m using two source files is that there is a lot of source code that connects to my database and whatnot. I have one person that’s gonna muck with the db stuff and another person to muck with the other logic. I’d prefer to have these files separate so they don’t have to muddle through code that they don’t need to look at

Answer 1

Yes and no. Yes, you can have as many partial classes as you wish. No, you cannot (nor do you have to!) specify them in your Page directive.

<%@ Page          Language='C#'          inherits='Default' %> 

in Default.aspx.cs:

public partial class Default { /*yadda*/ } 

in Default2.aspx.cs:

public partial class Default { /* even more yadda */ } 

Partial classes are an illusion of the compiler. They don’t exist as far as the CLR is concerned. The C# compiler stitches all the partial classes together during compilation; from the viewpoint of the asp.net compiler there is only one Default class.

---

Sounds like from your update that what you need is not multiple partial classes but to refactor your code. You should drop the idea of partial classes and go with dependency injection/inversion of control. Separate out your db logic and other areas of concern, define them using interfaces, and then, at runtime, inject the desired implementation of these ‘providers’ using a DI container framework.

This separates out your code and gives your application much more flexibility, testability and ease of updating; much better than just splitting code into two or more files. DI is pretty simple to understand and implement, also. I’m using Unity for DI and love it. It took about a day to get up to speed on it.