1

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

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

我的项目网

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

我的项目.DLL

作为基本命名空间，我将此 DLL 用于通常需要消耗的文件。例如，我的项目中包含所有枚举的类“枚举”就住在那里。与所有异常处理的类 MyProjectException 一样。

我的项目.IO.DLL

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

MyProject.Utilities.DLL

我所有的常用类和方法都集中在一个通用的 DLL 中。每个类都遵循“XHelper”约定，例如“SqlHelper、AuthHelper、SerializationHelper 等等……

我的项目.Web.DLL

我使用这个 DLL 作为主客户端接口。现在，这里的大多数类文件是：

1) 属性（例如学校、位置、帐户、帖子） 2) 授权内容（例如自定义成员资格、自定义角色和自定义配置文件提供者）

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

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

感谢您的回复并感谢您的耐心等待。

4

1 回答 1

0

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

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

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

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

于 2010-04-16T00:40:29.747 回答