Reputation: 2110
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
Upvotes: 3
Views: 1686
Reputation:
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.
Upvotes: 6
Reputation: 6143
While not a direct answer to your question, have you considered inheriting from a base page to merge the code?
In your Default.aspx.cs:
public partial class Default : CustomBasePage
{
protected void Page_Load(object sender, EventArgs e)
{
}
}
In your CustomBasePage.cs:
public class BasePage: System.Web.UI.Page
{
protected override void OnPreInit(EventArgs e)
{
base.OnPreInit(e);
//Your custom code
}
}
If you need to override events methods etc. in your default.aspx.cs, be sure and call the base methods.
Upvotes: 0