这可能根本不可能，但我想在我们放弃这个想法之前，我会得到你的回应。
我们有三个主要项目都在一个解决方案：接口、逻辑和数据访问。数据访问项目包含所有对象类及其变量和方法。逻辑项目包含保存逻辑方法的类和处理从数据访问项目中保存和加载对象的两个类。Interface项目是用户界面，任何需要在这里/不需要在逻辑层的类和方法。
我们打算保持一个明确的分离，并保持接口--〉逻辑--〉数据访问的通信，并以同样的方式返回。这一切都很好，但不幸的是，为了让接口理解数据访问类对象及其值，我们显然需要在接口项目中添加对数据访问项目的引用。
希望我还没有失去任何人？
现在，显然我们可以允许接口从数据访问项目中读取值，但我们不希望接口项目调用任何方法，因为这些方法都是通过逻辑层以特定方式处理的。我知道这只是一个设计时的问题，但无论如何，我们可以设置方法，不能从某些项目调用？我们不想在运行时捕获什么项目正在调用方法，因为这太晚了。
这听起来像是一个矫枉过正的问题，但由于我的同事和我可能不是唯一的开发人员，在它发布给公司后，我们希望任何其他开发人员都遵循解决方案和项目的严格指导方针和结构。我们可以把它全部写下来，并试图确保他们在应用程序工作之前阅读它，但正如我们都知道的那样，如果你被紧急要求在某个地方工作，你不能保证你有时间阅读另一个开发人员关于应用程序的技术规范。
如果您需要任何更多的信息来提出任何解决方案，请随时询问。
谢谢大家，
路易斯·罗素
6条答案
按热度按时间fgw7neuy1#
您可以使用
InternalVisibleTo属性，并标记要限制访问的方法internal。注意：在你的情况下，我不会使用它。我宁愿重新考虑设计。域对象位于“数据访问项目”中似乎有点奇怪。为什么你没有一个UI项目，一个逻辑项目，一个数据访问项目和一个模型项目？
lvjbypge2#
出现问题是因为您允许顶层（用户界面）引用底层（数据访问）的类型。不要这样做。*
相反，定义一些抽象（接口或基类），用户界面应该针对这些抽象进行编程。您可以将这些抽象放在逻辑层或新的库中。
然后，您的数据访问库应该实现这些抽象。
您可以使用依赖注入（DI）在运行时将真实的的数据访问库注入到用户界面中，而实际上这两者之间没有任何硬引用。
这可以手动完成，也可以通过使用DI容器（如Castle温莎）来连接依赖项。
gcmastyq3#
您可以抽象数据存储类（即即你传递的类）到一个单独的项目中，这个项目被数据访问和接口项目引用。然后可以从接口项目中移除数据访问项目引用。
w6mmgewl4#
您应该 checkout Managed Extensibility Framework以进行依赖注入。...
nkoocmlb5#
我通常不推荐这样做，但是你可以添加一个Debug时间检查，查看StackTrace，看看父级对象是什么。基本上，您将沿着跟踪向上走，直到遇到上面的级别（通过检查相关类型的程序集）--如果您没有遇到它（即：你到达了顶级程序集），然后你会抛出一个异常。
之所以只使用Debug，是因为您不想用实际上是冗余的代码来加重发布应用程序的负担。
bpsygsoo6#
也许把这些接口放在逻辑项目中会更好？如果你看看一些思想流派，如领域驱动设计，数据访问的接口（在DDD情况下，存储库接口）实际上是领域（又名逻辑）关注点（而不是数据层）的一部分，因此通常会在不同的项目中结束。