在C#项目之间添加引用的经验法则?

事实上,你不能有循环引用,但说实话,如果所有这些引用之间都有相互依赖性,那么将解决方案拆分为小项目会有什么好处呢?

通常在我打开Visual Studio之前,我会拿一张纸,把我的问题分成逻辑功能区。您可以在顶部绘制实用程序集,在底部绘制所有GUI、web服务和其他最终项目。公用事业项目不会引用任何其他项目,底部的项目也不会被任何项目引用。然后你会想这些有什么共同的功能,例如所有GUI都可以与共同的用户控件和对话框共享一个共同的UI项目,这个UI项目将引用“对象模型”项目等。底部的项目只能参考它们上面的项目。

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

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

这有点老套,但要帮助决定如何拆分为项目,你可以在维基百科上查找“耦合”和“内聚”。

此外,虽然我们有时认为这些决定是“风格”而不是“实质”,但我们应该记住,程序集边界对编译器和运行时都有意义。举几个例子。..

1. C#编译器理解一个名为“internal”的关键字。为了做出关于将因素分解为单独项目的最佳决策,你应该真正理解这一点的力量。

2. 运行时中的JIT编译器永远不会内联跨越程序集边界的函数调用,这会影响性能。(原因与代码访问安全有关)。

还有更多的例子,所以这个决定确实会有所不同。

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

例子。实体 -这个项目将包含我的业务对象和相关的类继承

例子。达尔 -我将所有业务逻辑和数据访问逻辑放在这个项目(名称空间)中。这是加载业务对象并将其传递到另一层的代码。

例子。图形化使用者介面 -我把所有的Winforms和GUI实用程序代码以及我的“main”启动输入方法都放在这里。您也可以选择将此项目称为示例。我仍然喜欢使用名称空间Example。Gui用于代码分离。

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

我试图将代码导入 实体 如果它属于某个业务对象或业务对象集合。

Gui将引用实体和Dal(数据访问层)。 根据你写Dal的方式,它可能会引用你的实体。 测试应该参考Entities、Dal,也许还有Gui。

实体是它自己的程序集dll,因此您可以在其他项目中使用它。或者把它们从一个。NET SOAP服务。

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