我在.net c＃应用程序中工作，该应用程序包含2个客户端和服务器解决方案。在服务器端，有80多个项目用于分离以下建筑层，
此外，几乎每个层都有测试项目。现在，解决方案的构建时间需要2到3分钟，许多开发人员（包括我:)认为我们需要解决这个问题。
因此，建议的解决方案是通过合并项目来减少项目数量。在我看来，这可能是一个很好的解决方案，可以最大限度地缩短构建时间，我们可以实现我们想要的目标。
建议的解决方案是我们将项目合并为3个区域，例如一个用于生产代码的库，一个用于测试代码的库，一个用于部署项目（WCF主机等）和在同一项目中逻辑划分的层，通过分离命名空间。
然而，我担心的是
还有其他方法可以分层解决方案吗？
答案 0 :(得分：4)
为什么80多个项目在您的应用程序中只有6层？
您可能会回答它们涵盖了大量功能区域，但您是否首先需要在一个解决方案中使用所有这些功能区域？
我建议将架构部门与项目和功能性部门一起反映到解决方案中。不同的解决方案可以重用相同的项目这样，每个可重用的体系结构层都有一个项目，并且有多个Domain项目和功能区域。
答案 1 :(得分：3)
我猜你应该在逻辑层中拆分你的解决方案。
作为你把助手放在哪里的一部分。在其中一个最低级别上为它制定解决方案。
示例
农场软件。你需要跟踪你的动物和蔬菜。你需要一个饲养动物的模块和一个将动物和蔬菜卖给消费者市场的模块。
这可以在以下解决方案中分开
返回端
每个后端模块都可以拥有自己的数据访问层，DTO，WCF服务......
此解决方案仅包含业务逻辑，数据访问，....并且可以有多个前端解决方案连接到这些后端解决方案。
<强>前端
这对您的项目来说是一个巨大的变化，这将产生影响。如果你不想改变它，请确保你认为这是真的。
多个解决方案将增加您的整体构建时间，并且每晚开发人员都可以使用最新的二进制文件，而无需在本地计算机上构建所有解决方案。
请注意，您仍然可以在不同的解决方案中使用您的图层：
让所有这些工作在一起并且不要弄乱二进制文件。您可以映射驱动器I.E. X：你有一个文件夹二进制文件，你有一个文件夹为每个解决方案。其中每个解决方案都复制了post build事件上的程序集。 （编写此脚本，因此它适用于每台机器）
如果您有良好的网络基础设施，您也可以将其复制到服务器上。因此，当您在TFS中构建所有解决方案时，它可以将其复制到所有开发人员都可以访问的位置。
如果您在TFS中构建，请确保构建顺序正确，首先是最低层，最后一层是最后一层。
但是当您分解解决方案时，在解决方案中，您可能并不需要在每个解决方案中使用它们。
我最近阅读了一篇关于Onion Architecture的文章，也许您也可以看一下。 （它特定于ASP.NET MVC）。
您还可以查看CQRS。
答案 2 :(得分：2)
我绝对不会合并这些项目...我认为你很快就会在每一层都找到意大利面条代码，因为开发人员会采取他们不应该采取的快捷方式（无论他们是否意味着）。 / p>
我更倾向于将各层分成单独的解决方案......并使用二进制引用而不是跨层的项目引用。这可能会对分支造成严重破坏，但要小心。
通过将项目构建到一个公共场所，我看到构建时间下降了 - 显然这可以防止VS重建项目时不需要 - 但我不知道这是否属实。
这里有一些想法：http://blogs.microsoft.co.il/blogs/arik/archive/2011/05/17/speed-up-visual-studio-builds.aspx
最后......是完整构建的三分钟还是单元测试一个项目？专注于最大的问题。如果单元测试需要很长时间，那么您就会遇到依赖性问题。如果完整的解决方案需要很长时间，请获取构建服务器并专注于降低单元测试开发时间。
希望有所帮助
答案 3 :(得分：1)
我过去处理过类似问题的低影响方式是创建一系列解决方案文件，其中只包含一个项目及其测试项目（可能还有项目的依赖项）。然后，给自己一个像NCrunch这样的工具，并在这些解决方案中完成大部分编码，可能使用TDD。这将为您提供闪电般快速的反馈循环，并且绝对是分层，分离方法的精神。当我过去做过这个时，我发现我实际上每天只运行整个应用程序几次，最多，而且我非常依赖红绿色重构，无论如何这很好。
如果你愿意，你甚至不需要控制这些小的解决方案文件 - 开发人员可以自己创建它们，它们可以被临时删除。
当然，这绝不是灵丹妙药，并不能解决您希望运行应用程序时编译时间长的问题，但它肯定有助于同时缩短反馈时间，同时促进良好的设计/开发实践它具有风险极低且设置快速的优点。