在C＃项目之间添加引用的经验法则？

Question

我对解决方案中项目之间的引用有疑问。我以前的大部分应用程序在解决方案中都有一两个项目，但这次我想进一步划分应用程序。

我现在开始在Visual Studio 2008中创建一个新的解决方案，并创建了几个基础项目来划分我的应用程序的单独部分。

但是目前我只是随心所欲地创建不同的项目，并在需要时在它们之间创建引用。有时我最终会遇到两个项目需要引用彼此的情况，但这是不允许的，因为它会导致循环依赖。

当我创建不同的项目并将它们链接在一起时，我是否应该记住任何规则/提示/模式？

我应该从内部开始出去吗？让“核心”项目参考所有外部项目，或者从外部和独立项目都参考“核心”？或者我有两个项目业务的第三个选项，他们都参考了第三个项目？

Answer 1

事实上，你不能有循环引用，但说实话，如果你的解决方案之间有相互依赖关系，将解决方案分解成小项目有什么好处？

通常在我打开Visual Studio之前，我会拿出一张纸并将问题分解为逻辑功能区。您可以在顶部绘制一个实用程序集合，并在底部绘制所有GUI，Web服务和其他最终项目。公用事业项目不会引用任何其他项目，而底层的项目不会被任何东西引用。然后你认为这些功能是常见的，例如所有的GUI都可以共享一个通用的用户控件和对话框的UI项目，这个UI项目将引用“对象模型”项目等。底部的项目只能引用上面的项目。

通常，当您需要循环引用时，您可以通过在较低级别的程序集中定义一个接口并在较高级别提供实现来很好地实现它。

不知道你到底在做什么，恐怕这是我能给你的唯一建议。

Answer 2

这有点过时，但为了帮助决定如何拆分项目，可以在维基百科中查找“Coupling”和“Cohesion”。另外，尽管我们有时会将这些决定看作“样式”而不是“实质”，但我们应该记住，装配边界对编译器和运行时都有意义。几个例子...

1. C＃编译器了解一个名为“内部”的关键字。为了做出有关分解项目的最佳决策，您应该真正理解这一点的力量。

2. 运行时的JIT编译器不会内联跨越汇编边界的函数调用，这会影响性能。 （原因是使用代码访问安全性）。

还有更多的例子，所以这个决定确实有所作为。

Answer 3

我将使用Winforms应用程序作为示例。我开始进入的模式是这样的。该解决方案称为示例。

Example.Entities - 该项目将包含我的业务对象和类的相关heirachy

Example.Dal - 我把所有的业务逻辑和数据访问逻辑在这个项目空间（namespace）这是加载业务对象然后将它们传递给另一个层的代码。

Example.Gui - 我把我所有的Winforms和GUI实用程序代码放在这里和我的'main'入口方法。你也可以选择调用这个项目的例子。我仍然喜欢使用名称空间Example.Gui进行代码分离。

示例测试 - 您可以将所有测试代码放在此项目中。

我尝试将代码驱动到实体，如果它属于业务对象或业务对象集合之一。

Gui会引用实体和Dal（数据访问层）。 根据你如何编写你的Dal，它可能引用你的实体。 测试应引用实体，Dal和Gui。

实体是它自己的程序集DLL，以便您可以在其他项目中使用它。或从.NET SOAP服务返回它们。

GUI层应该将DAL的内部视为黑匣子。您的主应用程序不应该关心业务对象如何加载或保持。但是你应该使用你的测试项目来彻底测试你的DAL。