每个业务对象都有一个包含SQL调用的匹配对象。我想的方式，他们只能用于由匹配业务对象限制这些SQL对象。如何才能实现这一目标？

更新

格雷格提出了关于可测试性的地步。由于SqlObjects将含有非常业务流程特定的SQL我不想让他们在多个理财周报对象重用。 （基本CRUD操作都是code-产生的）有没有一种方法，使SqlObjects访问的业务组件（如yshuditelu和格雷格山毛榉显示），只有一个业务对象和SqlObjects暴露在单元测试程序集 解决方案

如果这是你想要或需要服用，可以使SQL对象的业务对象中的私有类。该方法

 公共类BusinessObject的
{
    私有类SQLObject的{}
}
 

此外，通过使用部分类的，你可以分开处理成单独的文件，如果需要的。

  //在一个文件中
公共部分类BusinessObject的
{
    //业务对象实现
}

//在另一个文件
公共部分类BusinessObject的
{
    私有类SQLObject的{}
}
 

乔尔一个好点下面的SQLObject的仍然可以从一个共同的类型继承，一个评论说，像连接信息可以在那些内部类的共享。这是千真万确的，而且可能非常有益的。

在回答您的编辑，单元测试只能测试公共类和函数（没有在测试中使用反射）。唯一的选择我能想到的，将做到这一点：

此外，在这一点上，你就不必保留SQL对象作为嵌套类。总体来说，我认为这很可能会比它增加值增加更多的复杂性，但我完全明白，每一种情况是不同的，如果您的要求/期望推动你，祝你顺利。就个人而言，我想我会跟制作SqlObjects上市（或内部与内部可见的单元测试），并接受一个事实，即意味着SQL类接触到所有的业务类。

Each business object has a matching object that contains sql calls. I'd like to restrict these sql objects in a way where they can only be used by the matching business object. How can this be achieved?

Update

Greg brought up the point about testability. Since the SqlObjects will contain very business-process specific sql I don't want them reused in multiple buiness objects. (Basic CRUD operations are all code-generated) Is there a way to make the SqlObjects accessible to only one business object in the business assembly (like yshuditelu and Greg Beech showed) AND expose the SqlObjects to the unit testing assembly?

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:

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.