我对解决方案中项目之间的引用有疑问。我之前的大多数应用程序在解决方案中只有一个或两个项目，但这次我想进一步划分应用程序。
我现在正在Visual Studio 2008中启动一个新的解决方案，并创建了几个基础项目来划分我的应用程序的各个部分。
但是目前我只是随心所欲地创建不同的项目，并在需要时在它们之间创建引用。有时我最终会遇到两个项目需要互相引用的情况，但这是不允许的，因为它会导致循环依赖。
在创建不同的项目并将它们链接在一起时，我是否应该记住任何规则/提示/模式？
我应该从内部开始，然后出去吗？让“核心”项目参与所有外部项目，或者从外部和独立项目都引用“核心”的地方？或者我在两个项目中开展业务的第三个选项，它们都引用了第三个项目？
答案 0 :(得分：9)
确实你不能有循环引用，但说实话，如果你在所有这些项目之间存在相互依赖关系，将解决方案拆分成小项目有什么好处呢？
通常在我打开Visual Studio之前，我会拿一张纸将问题分成逻辑功能区。您可以在顶部绘制Utilities程序集，在底部绘制所有GUI，Web服务和其他最终项目。 Utilities项目不会引用任何其他项目，并且底部的项目不会被任何引用。然后你会想到这些功能的共同功能，例如：所有GUI都可以与普通用户控件和对话共享一个公共UI项目，这个UI项目将引用“对象模型”项目等。底部的项目只能引用它们上面的内容。
通常，当您看起来需要循环引用时，您可以通过在较低级别程序集中定义接口并在上层提供实现来很好地绕过它。
在不知道你在做什么的情况下，我担心这是我能给你的唯一建议。
答案 1 :(得分：4)
这有点过时了，但是在决定如何拆分项目时，你可以在维基百科中查找“耦合”和“凝聚力”。
此外，虽然我们有时将这些决定视为“风格”而非“实质”，但我们应该记住，汇编边界对编译器和运行时都有意义。几个例子......
C＃编译器理解一个名为“internal”的关键字。为了做出关于分解成单独项目的最佳决策，你应该真正理解它的力量。
运行时中的JIT编译器永远不会内联跨越程序集边界的函数调用，这会产生性能影响。 （原因与代码访问安全性有关。）
还有更多的例子，所以这个决定确实有所作为。
答案 2 :(得分：2)
我将以Winforms应用程序为例。我开始涉足的模式就是这个。该解决方案称为Example。
Example.Entities - 此项目将包含我的业务对象和类的相关heirachy
Example.Dal - 我将所有业务逻辑和数据访问逻辑放在此项目中（命名空间）这是加载业务对象然后将它们传递到另一层的代码。
Example.Gui - 我将所有Winforms和GUI实用程序代码放在这里，并将我的'main'开始输入方法。您也可以选择调用此项目示例。我仍然喜欢使用命名空间Example.Gui进行代码分离。
Example.Test - 您可以将所有测试代码放入此项目中。
如果代码属于某个业务对象或业务对象集合，我会尝试将代码驱动到实体中。
Gui将引用实体和Dal（数据访问层）。 根据您编写Dal的方式，它可能会引用您的实体。 测试应该参考实体，Dal，也许是Gui。
实体是它自己的Assembly dll，因此您可以在其他项目中使用它。或者从.NET SOAP服务返回它们。
GUI层应该将DAL的内部视为黑盒子。您的主应用程序不应该关心业务对象如何加载或持久化。但是你应该使用你的测试项目来彻底测试你的DAL。