关于.net中DLL的循环依赖关系的“最佳”实践是什么？
我正在尝试使用DLL来进行需要读/写XML的错误处理/日志记录 .
我已经有几个类来帮助在单独的“实用程序”类型DLL中进行XML操作 .
将我的fancy-pants错误处理类合并到实用程序DLL中会很好，但我还需要用于错误记录DLL的XML操作代码 .
我想我应该保持DLL的分离，以便在其他项目中重复使用，但现在我不确定最好的方法是什么 .
有关如何处理此方案的任何建议？
处理它的一种方法是将一个部件合并到另一个部件的组件中 . 我的经验是，人们倾向于将他们的项目分成许多小组件，这些组件并没有真正改善任何东西，但会导致依赖性问题 .
我一般都提倡很少的大集会 . 使用程序集作为部署单元，而不是构造代码 . 使用命名空间构建代码 .
解决此问题的另一种方法是在公共程序集中或在两个现有程序集之一中引入接口 . 如果接口方法本身不具有循环依赖性但方法体具有循环依赖性，则后一种情况是有意义的 .
下面是两本白皮书，深入探讨了.NET程序集和命名空间中代码分区的主题，涵盖了循环依赖的原因和方式 . 它与usr建议的方向相同：很少有大型程序集，使用程序集作为部署单元，而不是构造代码 . 使用命名空间构建代码 .
Partitioning code base through .NET assemblies and Visual Studio projects（8页）
创建程序集的常见有效和无效原因
提高Visual Studio解决方案编译性能（最高可达x10）
组织开发环境
Defining .NET Components with Namespaces（7页）
在.NET程序集中定义组件
组件之间依赖关系的非循环图
进化设计和非循环组件化
2 回答
处理它的一种方法是将一个部件合并到另一个部件的组件中 . 我的经验是，人们倾向于将他们的项目分成许多小组件，这些组件并没有真正改善任何东西，但会导致依赖性问题 .
我一般都提倡很少的大集会 . 使用程序集作为部署单元，而不是构造代码 . 使用命名空间构建代码 .
解决此问题的另一种方法是在公共程序集中或在两个现有程序集之一中引入接口 . 如果接口方法本身不具有循环依赖性但方法体具有循环依赖性，则后一种情况是有意义的 .
下面是两本白皮书，深入探讨了.NET程序集和命名空间中代码分区的主题，涵盖了循环依赖的原因和方式 . 它与usr建议的方向相同：很少有大型程序集，使用程序集作为部署单元，而不是构造代码 . 使用命名空间构建代码 .
Partitioning code base through .NET assemblies and Visual Studio projects（8页）
创建程序集的常见有效和无效原因
提高Visual Studio解决方案编译性能（最高可达x10）
组织开发环境
Defining .NET Components with Namespaces（7页）
在.NET程序集中定义组件
组件之间依赖关系的非循环图
进化设计和非循环组件化