链接文件和添加另一个项目作为参考之间的区别？

Question

我有一种情况，我有要在 1 个以上应用程序中使用的功能。特别是，我Repository采用了 C# 类库的形式，其中包含 EF .edmx、存储库和 UnitOfWork 之类的内容，这些内容足够通用，可以跨应用程序使用。

我很沮丧，我不能更清楚地看到图片，因为我应该清楚地了解差异；我做到了一点。但是，我认为我无法看透每个选择的后果和整体差异。

我已阅读此链接：您如何在 Visual Studio 中的项目/解决方案之间共享代码？它提供了一些很好的建议，但这两个建议似乎都站得住脚。我想更好地了解每种产品的下游影响，并了解哪种选择适合我的需要。

我相信通过链接文件，我会在 Application-2 中创建另一个新 Repository项目，但使用链接文件作为新层的组成部分。

我相信将Repositoryfrom Application-1添加为对 Application-2的引用会起作用，但我不确定更改代码会产生什么影响。

我基本上需要知道哪种方法会产生正确的结果来满足我在 1..n 应用程序之间共享存储库层的需要？

Answer 1

如果你有一个 Repository/UnitOfWork 的实现，你想在多个独立项目之间共享它，你有以下选择：

1. 将源 *.cs 文件放在某个公共文件夹中，并将这些文件作为链接添加到每个项目中。

   优点：

   • 所有错误修复/功能都会自动进入所有项目。
   • 您可以调试存储库代码。
   • 由于代码作为一组文件共享，因此每个解决方案都可以拥有自己的自定义数据访问项目，该项目可以扩展基本共享存储库代码。

   
   缺点：

   • 在两个已编译的项目中重复相同的代码，如果在某个时候 project1 将根据 project2 启动，则会出现类名/命名空间冲突，您必须手动解决该冲突（请参阅下面 Tom Blodget 的评论）。
   • 必须小心更改共享类的代码，不要破坏现有功能（例如，删除已在其他项目中使用的存储库方法）。
   • 如果共享代码链接到多个库中，则与复制粘贴基本相同。

   
   

2. 将公共代码提取到类库中，将编译后的 .dll 程序集作为引用包含在两个项目中。

   优点：

   • 防止意外的合同变更。
   • 可能有单一版本的 Repository 实现 - 在 GAC 中注册
   • 可以完全隐藏实现细节（使存储库内部/密封），并且仅公开接口。
   • 类库就像黑盒一样，迫使你实现更好的合约接口/API。

   
   缺点：

   • 可能需要支持多个版本的程序集，例如，当 project1 需要库 v2.0 的新功能时，v2.0 包含阻止其在 project2 中使用的破坏性更改。

   
   

3. 提取到单独的类库并包含库作为项目引用

   优点：

   • 与选项 1 相同，只是将 Repository 代码封装到一个共享库中，并作为一个完整的解决方案进行部署。扩展它可能会导致重大更改。

   
   缺点：

   • 减少对更改的控制，如选项 1 - 更改库中的源代码可能导致其他项目中的潜在破坏性更改。

但同样，这完全取决于许多因素 - 您使用的是哪种版本控制，您的项目的生命周期是什么，是否有多个团队开发这些项目，这些项目将如何部署以及它们是否将被连接。这一切都会影响最终的决定。