C＃类方法只能从某些项目中调用？

Question

这可能根本不可能，但我认为在我们放弃这个想法之前我会得到你的答复。

我们在一个解决方案中有3个主要项目：接口，逻辑和数据访问。 数据访问项目包含所有对象类及其变量和方法。 Logic Project包含保存逻辑方法的类，还包含2个类，用于处理从数据访问项目中保存和加载对象。 Interface项目是User接口，需要在此处/不需要在逻辑层中的任何类和方法。

我们打算保持清晰的分离并保持界面的沟通 - ＆gt;逻辑 - ＆gt;数据访问和返回相同的方式。这很好，但不幸的是，接口要理解通过其值传回的数据访问类对象，我们显然需要在接口项目中添加对数据访问项目的引用。

希望我没有失去任何人？

现在很明显我们可以让Interface从数据访问项目中读取值，但我们不希望接口Project调用任何方法，因为这些都是通过逻辑层以特定方式处理的。我知道这只是一个设计时问题，但无论如何我们可以将方法设置为不能从某些项目调用吗？我们不想捕获在运行时调用该方法的项目，因为这太晚了。

这可能听起来像是一个矫枉过正的问题，但由于我的同事和我可能不是唯一一个在公司发布之后就此工作的开发人员，我们希望其他任何开发人员都遵循严格的解决方案和项目的指导方针和结构。我们可以把它写下来并尝试确保他们在处理应用程序之前阅读它但是我们都知道如果你迫切要求你做某事，那么你无法保证你有时间阅读其他开发者技术首先说明应用程序。

如果您需要更多信息来提出任何解决方案，请随时提出。

非常感谢大家，

Louis Russell

Answer 1

您可以使用InternalVisibleTo属性，并标记要限制访问的方法internal。

注意：在你的情况下，我不会使用它。我更愿意重新考虑设计。您的域对象位于“数据访问项目”中似乎有点奇怪。为什么没有UI项目，逻辑项目，数据访问项目和模型项目？

Answer 2

您可以将数据存储类（即传递的类）抽象为由数据访问和接口项目引用的单独项目。然后，您可以从界面项目中删除数据访问项目引用。

Answer 3

出现问题是因为您允许顶层（用户界面）引用底层（数据访问）中的类型。 不要这样做。

相反，定义用户界面应编程的一些抽象（接口或基类）。您可以将这些抽象放在逻辑层或新库中。

然后，您的数据访问库应该实现这些抽象。

您可以使用依赖注入（DI）在运行时将真实的数据访问库注入用户界面，而不会在这两者之间实际存在任何硬引用。

这可以手动完成，也可以使用Castle Windsor等DI容器来连接依赖项。

Answer 4

您应该检查Managed Extensibility Framework依赖注入....

Answer 5

我通常不建议这样做，但你总是可以添加一个查看StackTrace的Debug time check来查看父级对象是什么。基本上，你走过轨迹，直到你遇到上面的级别（通过检查相关类型的程序集） - 如果你没有遇到它（即你到达顶级程序集），那么你将抛出异常

仅作为Debug的原因是，您不希望使用有效的冗余代码来增加发布应用程序的负担。

Answer 6

将这些接口放在逻辑项目中可能会更好吗？如果你看一下像Domain Driven Design这样的思想流派，那么数据访问的接口（在DDD案例库接口中）实际上是Domain（又称逻辑）关注的一部分（而不是数据层），所以经常会出现这种情况。一个不同的项目。