oData.net 是否可以实现微服务
Is it possible to implement microservices with oData.net
我一直在阅读 Microservice Architecure and with the limited valuable information available on internet, I believe, I have a fair understanding of it from the theory point of view. I understand that on a high level this architecture suggests to move away from monoliths and have small, independent services. However, all the examples that I see on the internet are suggesting to write loosely coupled windows services (daemons in case of non MS implementations) connected to an ESB. I understand that writing small, loosely coupled web services that adhere to SRP 也符合微服务的要求。
也就是说，oData.Net 服务，其中所有 oData 控制器（微服务？）都部署为一个整体，这明显违反了微服务架构模式。 oData.net 不是为微服务而设计的，这样的说法正确吗？如果您的回答是否定的，请举例说明。另外，帮助我理解如何混合使用 API 网关模式。
ODATA确实适合微服务。但是，微服务并不适合 Odata。我的意思是，没有什么能阻止您在微服务中公开 OData。
但是，这样做通常会暴露微服务中的大量内部数据结构。这反过来会增加不同服务之间的耦合。这样一来，由于依赖关系，您将更难更改服务。
我个人的经验法则是从每项服务中暴露尽可能小的API。而且我公开的数据结构与内部数据结构不同。它们可能会被扁平化或不同内部实体中数据之间的联合。
我的理由是：如果您要创建单独的服务，请尽量将它们分开。否则，您只是在构建一个单体应用，恰好在几个不同的 windows 服务中 运行。
oData 作为公开微服务的方法是完全有效的；然而，显式公开 table 不是微服务。所以我不完全同意jgauffin。没有理由不能使用 oData 提供 API。我同意 JGauffin 的地方是 API 应该有一个小的平面足迹，与源或目标的详细数据结构分离。因此，由调用它的服务来转换 API，但这意味着 API 的通用格式可以重复使用，只要有业务需求，并且技术平台可以根据需要切换。
我一直在阅读 Microservice Architecure and with the limited valuable information available on internet, I believe, I have a fair understanding of it from the theory point of view. I understand that on a high level this architecture suggests to move away from monoliths and have small, independent services. However, all the examples that I see on the internet are suggesting to write loosely coupled windows services (daemons in case of non MS implementations) connected to an ESB. I understand that writing small, loosely coupled web services that adhere to SRP 也符合微服务的要求。
也就是说，oData.Net 服务，其中所有 oData 控制器（微服务？）都部署为一个整体，这明显违反了微服务架构模式。 oData.net 不是为微服务而设计的，这样的说法正确吗？如果您的回答是否定的，请举例说明。另外，帮助我理解如何混合使用 API 网关模式。
ODATA确实适合微服务。但是，微服务并不适合 Odata。我的意思是，没有什么能阻止您在微服务中公开 OData。
但是，这样做通常会暴露微服务中的大量内部数据结构。这反过来会增加不同服务之间的耦合。这样一来，由于依赖关系，您将更难更改服务。
我个人的经验法则是从每项服务中暴露尽可能小的API。而且我公开的数据结构与内部数据结构不同。它们可能会被扁平化或不同内部实体中数据之间的联合。
我的理由是：如果您要创建单独的服务，请尽量将它们分开。否则，您只是在构建一个单体应用，恰好在几个不同的 windows 服务中 运行。
oData 作为公开微服务的方法是完全有效的；然而，显式公开 table 不是微服务。所以我不完全同意jgauffin。没有理由不能使用 oData 提供 API。我同意 JGauffin 的地方是 API 应该有一个小的平面足迹，与源或目标的详细数据结构分离。因此，由调用它的服务来转换 API，但这意味着 API 的通用格式可以重复使用，只要有业务需求，并且技术平台可以根据需要切换。