0

我是我工作的公司的 Intranet 开发人员，过去 5 年我一直在做这件事。我的项目分为两个解决方案，“Intranet”解决方案本身和“Library”解决方案。“库”sln 本身有几个项目包含 DAL、BLL 等。我将它们保留在不同的解决方案中的原因是因为我认为“也许”，有一天我的库 sln 也可以用于其他项目- 你知道重用我已经写过的代码 :) 好吧，那从未发生过。现在，由于在同一个 .sln 中拥有所有项目非常容易，我正在考虑这样做。这是一个明智的情况吗？如果你在我的鞋子里，你会怎么做？

4

6 回答 6

2

过去，我在多个解决方案中使用并重用了同一个“项目”——我真的只是将解决方案视为项目集合的“特定”实例。

例如，我们可能对同一个整体软件有不同的解决方案，这取决于我们是要进行单元测试（在他们自己的项目中）还是集成测试（在单独的项目中），我们会打开正确的解决方案我们将要做什么。这样，如果您使用单元测试进行正常编码，则不必每次都构建集成测试代码，反之亦然。

唯一需要注意的是将一个项目引入一个依赖于许多其他项目/解决方案的解决方案，然后“意外地”更改其中的代码，而没有意识到它在一个辅助项目而不是你的主代码中。然后你可以开始打破依赖它但没有意识到的其他项目的负载！

于 2009-10-02T12:47:14.323 回答
0

是的，你可以做到！您仍然可以重复使用 DAL 和 BLL，因为项目设置存储在特定的项目文件（csproj、vbproj、...）中。依赖项也存储在那里，所以没问题，很好。我有一个插件基础设施，对于每个插件包，我确实需要插件主机，它包含在几个解决方案文件中。我从来没有遇到过任何问题。在文本编辑器中打开 *.sln 文件以查看其内容...只是指向项目的链接。

于 2009-10-02T12:38:58.020 回答
0

只需将您的库项目添加到您的 Intranet sln。保持您的图书馆解决方案不变。

于 2009-10-02T12:39:31.110 回答
0

我更喜欢有两种解决方案。它们都具有相同的结构（或多或少），但第二个仅包含与特定项目无关的可重用基础架构代码。问题是——你的项目代码不应该在严肃的银行业务逻辑旁边包含类似框架的（即'IsNumeric（）'字符串扩展方法）的东西（即使你不会重用你的'库'）。这只会让事情变得更具可读性和可维护性。

例如：

解决方案1：

  • 项目名称.Core
  • 项目名称.基础设施
  • 项目名称.应用
  • 项目名称.UI
  • 项目名称.IntegrationTests
  • 项目名称.UnitTests

和

解决方案2：

  • 公司名称.Core
  • 公司名称.基础设施
  • 公司名称.申请
  • 公司名称.UI
  • 公司名称.Tests

我尽量不要在 1 个解决方案中包含超过 10 个项目。否则 - 它会导致“卸载项目”/“重新加载项目”之间的无限切换。

于 2009-10-02T12:56:49.067 回答
0

我个人会将它们添加到同一个解决方案中，是的。也就是说，您是否计划在其他项目中使用解决方案中的某些库并不重要：您仍然可以将编译后的 dll 添加到这些解决方案中，或者您可以选择将它们作为现有项目添加到新解决方案中.

所以是的，我将所有内容都添加到同一个解决方案中：gui 项目、库，甚至单元测试。也许如果您的解决方案变得非常大（20 多个项目或更大），最好将它们拆分，但我从未从事过如此大的项目。

于 2009-10-02T12:40:21.047 回答
0

就我而言，我已经将解决​​方案和项目分开，给我留下了一大堆项目和几个解决方案文件。我在新解决方案中添加了我需要的所有项目。

好处是我的工作区中只有我真正需要的项目，并且在所有其他解决方案中它仍然会发生变化。缺点是它在所有其他解决方案中也会发生变化，这意味着如果您更改广泛使用的库的 API，则必须检查所有其他解决方案是否不兼容。

于 2009-10-02T12:42:34.200 回答