If this is the approach you want or need to take, you could make the sql objects private classes within the business object.
public class BusinessObject
{
private class SqlObject { }
}
Additionally, by making use of partial classes, you could separate this into separate files if desired.
//in one file
public partial class BusinessObject
{
//business object implementation
}
//in another file
public partial class BusinessObject
{
private class SqlObject { }
}
Joel makes a good point in a comment below "the SqlObject can still inherit from a common type, to that things like connection information can be shared across those "inner" classes." this is absolutely true, and potentially very beneficial.
In response to your edit, unit tests can only test public classes and functions (without using reflection in your tests). The only option I can think of that would do this is:
- make one assembly per business/sql object pair
- changing the
private class SqlObject
to internal class SqlObject
- then use the
[InternalsVisibleTo("UnitTestsAssembly")]
for the project
Also, at this point you wouldn't have to keep the sql object as a nested class. Generally speaking, I think this would likely add more complexity than the value it adds, but I completely understand that every situation is different, and if your requirements/expectations are driving you this, I wish you well. Personally, I think I would go with making the SqlObjects public (or internal with internals visible to for unit testing), and accept the fact that that means the sql classes are exposed to all of the business classes.