在同一解决方案中分离与具有不同命名空间的独立块相对应的代码而不是不同项目的缺点

Question

我正在开展一个项目，我的整个团队都面临以下问题，请帮助我发现与我们决定遵循的方法相关的问题，以便我们事先能够自救：）

我们决定在单一解决方案中将整个应用程序代码分成三个项目。

1）一个项目将包含整个用户界面 2）其次将包含整个业务逻辑。在这个项目中，对应于我们应用程序的不同模块的代码将通过不同的名称空间分隔，而不是为每个模块或相关模块分别设置项目。
3）第三个项目将包含所有公共代码

如果我们将整个代码放在单个dll中不同名称空间下的第二个项目中，而不是将它分成不同的dll /项目，我仍然可以看到将来可能会出现一些问题。 我们正在开发基于WPF的应用程序。

请帮忙！

Shahil Gautam

Answer 1

  

如果我们将整个代码放在单个dll中不同名称空间下的第二个项目中，而不是将它分成不同的dll /项目，我仍然可以看到将来可能会出现一些问题。我们正在开发基于WPF的应用程序。

执行此操作的唯一“问题”是，“意外”引用其他命名空间中的类型会更容易一些。如果您分成单独的项目，使用与其无关的业务逻辑“污染”您的类型的唯一方法是显式添加引用。当它在同一个项目中时，您可以使用using语句或完全限定的类型名称，并在没有任何编译器警告的情况下“使用”不相关的类型。

Answer 2

我认为这是明智的选择。我一般来说，程序集应该是部署单元。如果它们总是一起部署，则不需要有10个组件。

然而，一个问题是您必须更加小心项目中的依赖项。在将事物分成不同的项目时，存在引入不适当依赖关系的物理障碍，而现在您必须更加关注这一点。像ndepend这样的工具可以帮助您在代码中找到可疑的依赖项。

Answer 3

我不明白为什么您希望在业务逻辑项目中拥有多个名称空间。

有两种可能性：

ONE。您在项目中定义的所有类型都具有不同的非限定名称。

在这种情况下，分隔命名空间几乎没有用处。唯一的好处是，当省略对其他命名空间的使用时，智能感知对象的选择会更短更清晰。将类型放入单独的项目中也可以完成同样的事情，并提供更好的关注点分离。

TWO。不同名称空间中的某些类型具有相同的非限定名称。

在这种情况下，只要在尝试使用其非限定名称从另一个名称空间引用类型的失败尝试中添加来自另一个名称空间的using时，就很容易产生混淆。如果没有发生这种情况的危险，那么，再一次，为什么不将这些对象放入单独的项目中，因为很明显，这些域之间的线条是清晰的？