使用.NET Core框架似乎有很多好处，我们正在调查这些以查看是否/何时应该迁移我们的应用程序。
.NET Core中真正吸引人的哲学之一就是只使用所需的.NET框架部分，通过 Nuget软件包加载这些。
如果我们要迁移，那么我真的很喜欢我们自己的框架来反映.NET Core方法的精益。目前，它与完整的.NET框架方法更加相关，我们在这种方法中公平地加载了＃34; fat＆＃34; DLL文件。我没有看到关于如何最好地构建解决.NET Core的应用程序的任何具体建议，所以我在此处提出建议。
为简单起见，让我们假设我们只有两个应用程序：App-A和App-B。
两个应用程序都需要访问SQL中保存的数据，这些数据由存储过程访问。 App-A与App-B不同，但它们是相关的，因此您可以想象一些存储过程仅由App-A调用，一些仅由App-B调用，一些由两者调用。
调用这些存储过程的所有代码都保存在一个名为＆＃34; SQL-DLL＆＃34;的公共DLL中。是的，DLL公开了特定于App-A和App-B的接口，但DLL仍然包含所有代码，所以可以考虑＆＃34; fat＆＃34;而不是＆＃34;精益＆＃34;。
对于2个应用程序，可以考虑将其拆分为3个DLL：一个只包含对App-A的调用，一个仅用于调用App-B，一个用于所有常见调用。但是，如果你有（比方说）10个申请怎么办？排列变得更高，很快就不清楚哪些调用存在于DLL中。
最好将DLL拆分成更小的功能DLL - 有点像＆＃34;微服务＆＃34;？一个用于所有客户详细信息的DLL，一个用于所有订单详细信息的DLL，一个用于所有订单的DLL ....但是又有一个...＆＃34; GetCustomerOrders＆＃34;属于客户还是订单？嗯。
如果有人对保持.NET Core世界的代码精益有任何好的建议，请告诉我。
此外，每个应用程序都有一个Visual Studio解决方案，每个解决方案都有共享项目。有些人建议将共享库作为Nuget包而不是项目，但我认为这会使调试和TDD变得更加困难。对此的想法？
最后，如何最好地在源存储库（例如TFS）中组织它。目前，共享项目产生的相对路径包含大量的＆＃34; ../../"它在Visual Studio中工作正常，但是当Nuget包不在它们的预期路径中时，可能会在构建服务器上引起问题。
我知道我在这里问了很多，但是任何/所有的建议都会非常感激！
答案 0 :(得分：1)
如果您的App-A和App-B共享相同的业务层，那么为该层提供唯一的包/ DLL是有意义的。或者，您可以将此业务层公开为REST API。在这种情况下，您将拥有一个公开所有业务逻辑的App-C。
因此，如果您创建了App-C，那么您只需像管理应用程序那样管理开发/生产版本。
但是如果你决定将它用作DLL，你有两个选择：
第一个选项是Ok，如果您要在团队中使用它并为您提供调试的好处。但是如果其他团队打算使用它，我会将其作为产品进行管理并将其作为Nuget包提供。