使一个对象只能访问同一个程序集中的另一个对象？(Make an object accessible to only one other object in the same assembly?)

使一个对象只能访问同一个程序集中的另一个对象？(Make an object accessible to only one other object in the same assembly?)

每个业务对象都有一个包含sql调用的匹配对象。 我想限制这些sql对象的方式只能被匹配的业务对象使用。 这怎么能实现？

更新

Greg提出了关于可测试性的观点。 由于SqlObjects将包含特定于业务流程的sql，我不希望它们在多个buiness对象中重用。 （基本的CRUD操作都是由代码生成的）有没有办法让SqlObjects只能访问业务程序集中的一个业务对象（如yshuditelu和Greg Beech展示的）并将SqlObjects公开给单元测试程序集？

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?

最满意答案

如果这是您想要或需要采取的方法，您可以在业务对象内创建sql对象私有类。

public class BusinessObject { private class SqlObject { } }

此外，通过使用部分类，如果需要，可以将它分成单独的文件。

//in one file public partial class BusinessObject { //business object implementation } //in another file public partial class BusinessObject { private class SqlObject { } }

Joel在下面的评论中提到了一个很好的观点：“SqlObject仍然可以继承一个通用类型，因为连接信息可以通过这些”内部“类共享。” 这是绝对正确的，并且可能非常有益。

为了响应你的编辑，单元测试只能测试公共类和函数（不要在你的测试中使用反射）。 我能想到的唯一选择是：

为每个业务/ sql对象创建一个程序集 将private class SqlObject更改为internal class SqlObject 然后使用[InternalsVisibleTo("UnitTestsAssembly")]作为项目

此外，在这一点上，你不必将sql对象保持为嵌套类。 一般来说，我认为这可能会增加更多的复杂性，但我完全理解每一种情况都是不同的，如果您的要求/期望能够推动您的发展，我希望您一切顺利。 就我个人而言，我认为我会将SqlObjects公开（或者内部可见内部用于单元测试），并接受这一事实，即这意味着sql类会暴露给所有业务类。

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.