在单独的项目与单独的命名空间中组织代码答案

【问题标题】：Organizing code in separate Projects vs separate Namespaces在单独的项目与单独的命名空间中组织代码
【发布时间】：2012-10-09 17:15:47
【问题描述】：

我在一个 .net c# 应用程序中工作，其中包含 2 个用于客户端和服务器的解决方案。在服务器端，有 80 多个项目用于分离以下架构层，

基础设施层
集成层（外部系统）
域层
存储库层
经理层
服务层

此外，几乎每一层都有测试项目。现在，解决方案的构建时间需要 2 到 3 分钟，许多开发人员（包括我 :)）都觉得我们需要解决这个问题。

因此，建议的解决方案是通过合并项目来减少项目数量。在我看来，这可能是一个很好的解决方案，可以最大限度地减少构建时间，我们可以实现我们想要的。

建议的解决方案是我们将我们的项目合并为 3 个区域，例如一个用于生产代码的库，一个用于测试代码的库，以及一个用于部署项目（WCF 主机等）的库，并在同一项目中通过分离逻辑划分层命名空间。

但是，我担心的是

这些分离对可维护性有好处吗？为每个命名空间 appox 提供数百个类。
如果我们有一些常用的功能，比如助手，我们把它们放在哪里？

还有其他方法可以分层解决方案吗？

【问题讨论】：

我不确定制作更少的项目是否会使构建速度更快，代码量是否相同。我认为 VS 不会在组装项目上浪费太多时间。
为什么不把你的解决方案分成几个呢？

标签： c# .net architecture

【解决方案1】：

我猜你应该把你的解决方案分成逻辑层。

作为您将助手放在哪里的一部分。在最低级别之一上为它制定解决方案。

示例

农场软件。您需要跟踪您的动物、蔬菜。您需要一个用于喂养动物的模块和一个用于向消费者市场销售动物和蔬菜的模块。

这可以分为以下解决方案

后端

销售模块：销售您的产品的Everything
购买模块：为您的动物购买种子、食物、其他产品......
Sheduler 模块：播种、收割等触发事件...
预测模块：根据天气和市场价格预测收成数量...
...

每个后端模块都可以拥有自己的数据访问层、DTO、WCF 服务……

此解决方案将仅包含业务逻辑、数据访问、...。并且可以有多个前端解决方案连接到这些后端解决方案。

前端

ASP.NET MVC 应用程序：用于向消费者销售的网上商店
WPF 应用：批准销售
其他 WPF 应用程序：买东西。
移动应用程序：将事件发送到您的手机或其他设备上。
（另一种选择是将 2 个或更多后端解决方案连接到 1 个前端解决方案中）
...

这对您的项目来说是一个很大的变化，并且会产生影响。如果你不想改变它，请确保你认为这是真的。

多个解决方案将增加您的整体构建时间，并且每晚构建一个非常重要，这样每个开发人员都可以始终使用最新的二进制文件，而无需在其本地计算机上构建所有解决方案。

请注意，您仍然可以在不同的解决方案中使用您的图层：

基础设施层
集成层（外部系统）
域层
存储库层
经理层
服务层

为了让这一切一起工作，不要搞乱二进制文件。您可以映射驱动器 I.E. X：您有一个文件夹二进制文件，每个解决方案都有一个文件夹。每个解决方案都复制构建后事件中的程序集。（编写此脚本，使其适用于每台机器）

如果您有良好的网络基础设施，您也可以将其复制到服务器上。因此，当您在 TFS 中构建所有解决方案时，它可以将其复制到所有开发人员都可以访问的位置。

如果您在 TFS 中构建，请确保您的构建顺序正确，首先是最低层，最后是最高层。

但是当您拆分解决方案时，您可能不需要在每个解决方案中都使用它们。

我最近读了一篇关于Onion Architecture的文章，也许你也可以看看。（它特定于 ASP.NET MVC）。

您也可以查看CQRS。

【讨论】：

【解决方案2】：

为什么有 80 多个项目，而您的应用程序只有 6 层？

您可能会回答说它们涵盖了大量的功能领域，但您首先需要将所有这些功能领域放在一个解决方案中吗？

我建议将架构部门反映在项目中，将功能部门反映在解决方案中。不同的解决方案可以重用相同的项目。这样，您就可以为每个可重用的架构层创建一个项目，以及与功能区域一样多的领域项目。

【讨论】：

是的..好点。我们在不同的项目中有许多层的数据合同、运营合同。但是，我们的解决方案中也有许多外部系统项目，现在我认为我们应该将它们从解决方案中删除（如果适用）

【解决方案3】：

我绝对不会合并这些项目...我认为您很快就会在每一层中得到意大利面条式代码，因为开发人员会走捷径（无论他们是否有意）他们不应该走的路。

我更倾向于将层分离成单独的解决方案......并使用二进制引用而不是跨层的项目引用。不过，这可能会对分支造成严重破坏，请小心。

我已经看到通过将项目构建到一个共同的地方来减少构建时间 - 显然这可以防止 VS 在不需要时重建项目 - 但我不知道这是否属实。

这里有一些想法：http://blogs.microsoft.co.il/blogs/arik/archive/2011/05/17/speed-up-visual-studio-builds.aspx

最后....是完整构建的三分钟还是仅对一个项目进行单元测试？专注于最大的问题。如果单元测试需要很长时间，那么您就会遇到依赖关系问题。如果完整的解决方案需要很长时间，请获取构建服务器并专注于缩短您的单元测试开发时间。

希望有帮助

【讨论】：

【解决方案4】：

我过去处理类似问题的一种低影响方式是创建一系列解决方案文件，其中仅包含一个项目及其测试项目（可能还有项目的依赖项）。然后，给自己找一个像NCrunch 这样的工具，并在这些解决方案中完成大部分编码，可能使用 TDD。这将为您提供闪电般的快速反馈循环，并且绝对符合分层、解耦方法的精神。当我过去这样做时，我发现我实际上每天最多只运行整个应用程序几次，而且我严重依赖 red-green-refactor，这无论如何都很好。

如果您愿意，您甚至不必对这些小解决方案文件进行源代码控制 - 开发人员可以创建自己的文件，并且可以将它们扔掉。

当然，这绝不是灵丹妙药，也无法解决您想要运行应用程序时编译时间长的问题，但它绝对可以帮助减少反馈时间，同时促进良好的设计/开发实践它的优点是风险极低且设置速度快。

【讨论】：

酷。您还记得我们之前做过的一个项目。每个开发人员都有自己的解决方案文件，并将其保存在本地。但是，由于其他项目的冲突，我们经历了很多构建失败。