是否可以使用oData.net

Question

我一直在阅读有关Microservice Architecure的内容，而且我认为，互联网上提供的有价值的有限信息，我从理论的角度对它有一个公平的理解。据我所知，从高层次来看，这种体系结构建议远离monoliths并拥有小型的独立服务。但是，我在互联网上看到的所有示例都建议编写连接到ESB的松散耦合的Windows服务（非MS实现的守护进程）。我理解，编写符合SRP的小型，松散耦合的Web服务也适合微服务。

也就是说oData.Net服务，其中所有oData控制器（微服务？）被部署为整体，明显违反了微服务架构模式。是否正确声明oData.net不能用作微服务？如果您的答案是否定的，请在示例的帮助下解释。另外，请帮助我理解，如何在混合中使用API​​网关模式。

Answer 1

ODATA确实适合微服务。但是，微服务并不适合odata。我的意思是，实际上没有什么可以阻止你在微服务中暴露OData。

但是，通过这样做，您通常会在微服务中公开一大组内部数据结构。这反过来会增加不同服务之间的耦合。通过这样做，您可以更加难以根据依赖性更改服务。

我个人的经验法则是尽可能从每个服务中公开小API。我公开的数据结构与内部数据结构不同。它们可能是扁平化的，也可能是不同内部实体中数据之间的联合。

我的理由是：如果您要创建单独的服务，请尝试尽可能地将它们分开。另外，你只是在构建一个碰巧在几个不同的Windows服务中运行的巨型组件。

Answer 2

oData作为暴露微服务的方法完全有效;然而，暴露显式表不是微服务。所以我不完全赞同jgauffin。没有理由使用oData无法使API可用。我同意JGauffin的地方是，API应该具有小的，平面的足迹，其与源或目的地的详细数据结构分离。因此，由服务调用它来转换API，但意味着只要业务需要存在，就可以重用API的通用格式，并根据需要切换技术平台。