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

Question

我有一种情况，我想要在多个应用程序中使用我的功能。特别是，我有一个Repository采用C＃类库的形式，包含EF .edmx，repository和UnitOfWork之类的东西，它们通用，可以跨应用程序使用。

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

我已经阅读了这个链接：How do you share code between projects/solutions in Visual Studio?它提供了一些很好的建议，但这两个建议似乎都有用。我想更好地了解每个人的下游影响，并了解哪个是我需要的正确选择。

我相信链接文件我会在Application-2中创建另一个 new Repository项目，但是使用链接文件来构成新图层。

我相信将Application-1中的Repository作为引用添加到Application-2会起作用，但我不确定更改代码的影响是什么。< / p>

我基本上需要知道哪种方法会产生正确的结果，因为我需要在1..n应用程序中共享存储库层？

Answer 1

如果您有要共享的Repository / UnitOfWork的实现 在多个独立项目中，您有以下选项：

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

   赞成：

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

   
   缺点：

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

   
   

2. 将公共代码提取到类库中，包括编译的.dll程序集作为参考 进入这两个项目。

   赞成：

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

   
   缺点：

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

   
   

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

   赞成：

   • 与选项1相同，除了将存储库代码封装到一个共享库中，并将其部署为完整的解决方案。扩展它可能导致重大变化。

   
   缺点：

   • 减少对更改的控制，如选项1 - 更改库中的源代码 可能会导致其他项目发生重大变化。

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