代码组织难题：具有多个支持 DLL 的 Web 项目？

Question

我正在尝试掌握代码的最佳实践 我的项目中的组织。我环顾四周 互联网上有很好的例子，到目前为止，我已经看到 具有一个或多个支持的 Web 项目示例 它引用的类库或 Web 项目 遵循其命名空间约定的子文件夹。

假设没有正确的答案，这就是我目前的 用于代码组织：

我的项目网站

这是我的网站。我在这里引用我的类库。

MyProject.DLL

作为基本命名空间，我将这个 DLL 用于 一般需要消耗品。例如，我的班级“枚举” 那里有我项目中的所有枚举。作为 为所有异常处理做类 MyProjectException。

MyProject.IO.DLL

这是一组可能包含 20 个文件的文件，用于处理文件上传和 下载（到目前为止）。

MyProject.Utilities.DLL

我所有常用的类和方法都集中在一起 一般是消耗的DLL。每个类都遵循“XHelper”约定 比如“SqlHelper、AuthHelper、SerializationHelper等等……

MyProject.Web.DLL

我使用这个 DLL 作为主客户端界面。 目前，这里的大多数类文件是：

1) 属性（例如学校、位置、帐户、帖子） 2）授权的东西（如自定义成员，自定义角色， 和自定义配置文件提供商）

我的问题很简单——这看起来合乎逻辑吗？

另外，我如何避免从一个交叉引用 DLL 项目库到下？例如，MyProject.Web.DLL 使用来自 MyProject.Utilities.DLL 和 MyProject.Utilities.DLL 的代码 使用来自 MyProject.DLL 的代码。这是否通过单击属性并选择“依赖项”来解决？我试过了，但似乎仍然没有访问 我选择的程序集。我必须参考每个 每个类库我需要的程序集？

感谢您的耐心回复。

Answer 1

这是合乎逻辑的，因为它从您的假设中合乎逻辑地进行。你问这个问题的事实让我相信你可能不认为这是理性。

一般来说，应该按照概念边界而不是技术边界来分解事物。 MyProject.IO.DLL 是在您当前设计中体现这一原则的一个示例。所有的 IO 事物逻辑上结合在一起，因此它们最终形成一个二进制文件。有道理。

根据技术类型（枚举、类等）将事物分解为命名空间会有点问题。

依赖问题与将一个类分解为多个类的问题相同，它使用相同的技术解决：依赖反转。如果两件事情似乎需要相互依赖，请添加一个代表前两件合同的中间件。这可以是抽象、常量、中介等......无论你需要做什么，这样你就可以拥有 A 和 B 依赖于 C 的东西，而不是 A 依赖于 B，B 依赖于 A。