我正在尝试处理代码的最佳实践 我项目中的组织。我环顾四周 互联网是一个很好的例子，到目前为止，我已经看到了 具有一个或多个支持的Web项目的示例 它引用的类库或带有的Web项目 遵循其命名空间约定的子文件夹。
假设没有正确答案，这就是我目前的情况 有代码组织：
MyProjectWeb
这是我的网站。我在这里引用我的类库。
MyProject.DLL
作为基本命名空间，我将此DLL用于文件 需要一般消耗品。例如，我的班级“Enums” 我项目中的所有枚举都存在于那里。如 为所有异常处理类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中的代码。这是通过单击属性并选择“依赖关系”来解决的吗？我尝试过，但似乎仍然没有访问的命名空间 我选择的组件。我是否必须参考每一个 每个类库需要汇编吗？
回应表示赞赏，感谢您的耐心等待。
答案 0 :(得分：0)
合乎逻辑的是，它从你的假设出发。你问这个问题的事实让我相信你可能认为它不是理性的。
一般来说，事情应该沿着概念边界而不是技术边界进行细分。 MyProject.IO.DLL是您当前设计中出现的这一原则的一个示例。所有IO事物逻辑上都在一起，所以它们最终只有一个二进制文件。有道理。
根据他们的技术类型 - 枚举，类等 - 将事情分解为名称空间 - 会有点问题。
依赖性问题与使用多个类打破一个类的问题相同，并且使用相同的技术解决它：依赖性的反转。如果两件事似乎需要相互依赖，那就添加一个代表前两者之间契约的中间事物。这可以是抽象，常数，调解员等...无论你需要做什么，以便取代事物A取决于东西B和事物B取决于事物A，你有事物A和B取决于事物C。