2

我有一种情况，我想要在多个应用程序中使用的功能。特别是，我有Repository一个 C# 类库的形式，其中包含 EF .edmx、存储库和 UnitOfWork 等足够通用的东西，可以跨应用程序使用。

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

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

我相信通过链接文件，我会在 Application-2 中创建另一个新 Repository项目，但将链接文件用于构成该新层的内容。

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

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

4

1 回答 1

5

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

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

    优点：

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


    缺点：

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


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

    优点：

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


    缺点：

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


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

    优点：

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


    缺点：

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

But again, it all depends on many factors - what kind of version control you are using, what will be lifecycle of your projects, are there multiple teams developing these projects, how these projects will be deployed and whether or not they will be connected. It all affects the final decision.

于 2013-04-17T21:37:19.570 回答