我尝试在ASP.NET Core（Web API）上实现基于微服务的项目。 因此，我有一个独立的组件，可以在它们和外部世界之间进行通信。 因此，我在服务之间具有“连接点”-一个视图模型（输入数据）等效于其他请求/响应，依此类推。 我认为，这种情况有一些最佳做法，这些做法使我无法创建大量相同的代码，对吗？
让我们深入研究一下这种情况，例如，我在数据库和微服务中拥有数据，这些数据从DB获得（可能要转换或稍加修改）信息并将其提供给询问者。是否可以不创建用于存储和响应数据库信息的重复代码？
谢谢。
答案 0 :(得分：1)
您在说的是模型。输入模型和输出模型（DTO）。
如果您的项目属于同一解决方案，那么您可能可以使用共享的项目或类库来重用模型。
如果没有，请创建一个NuGet软件包，通过您自己的feed分发它，并在需要它的所有项目中使用它。
为了使其正常工作，您需要使该项目非常简单。它最好不具有任何依赖关系，因此您可以引用它而不会产生意想不到的后果。如果保持非常简单，则可以很好地工作。
答案 1 :(得分：1)
主要取决于您的用例，总体意图和解决方案体系结构。
从开发和部署的角度来看，微服务的意思是自治的，它们不应该了解自己或了解得很少。他们对其他微服务的了解越多，耦合度就越高。他们应该拥有其创建所需要的模型和数据（以履行其职责）。您可以使用event based integration来实现此目的。
在这种情况下，我认为不需要任何代码重用。每个微服务背后都有不同的输入和逻辑。您应该在项目中为此努力。
如果您的微服务太闲谈（例如，它们经常需要向其他微服务询问数据），则您可能在其边界上犯了一个错误，您应该考虑重新设计它们。另外，您应该避免创建仅是其数据库浏览器的微服务。
接下来要指出的是DRY原理，以及为什么这不适用于微服务领域。在OOP世界中，使用此原理很普遍。这就是为什么大多数开发人员将尝试在微服务世界中使用它的原因。但是，如果您尝试将其应用于微服务，则会导致高耦合，并且您将无法真正独立地开发它们。代码重用和数据冗余并不像您想象的那么糟糕。
总结一下。正如我刚开始所说的取决于。如果您的“微服务”是一种解决方案的一部分，并且例如在代码中引用它们，则您实际上不能为其命名微服务，而可以使用Andrei所说的解决方案。但是，如果它们不是，并且您真的在乎它们的独立性（并且遵循我在上文中提到的内容），则您不应该在不同的微服务之间共享代码，并且实际上不需要。但是，如果不同的微服务确实使用相同的代码（即使它们的设计合理），则不要害怕，只需重用相同的代码即可。您会看到它会得到回报。
微服务并不是满足所有需求的灵丹妙药，您应该意识到这一点。作为进一步的参考，我建议您免费使用book。