清洁体系结构外部REST API作为适配器
我正在研究干净的体系结构，并且正在努力整合外部REST API。我将在应用程序层中定义API的接口，并将实现放入基础架构层。
但是在哪里存储外部API的DTO/模型？
我是否必须创建一个映射，以免将模型存储在核心层中？在我看来，这是正确的方法，但是当我尝试使用NSWAG生成客户端时，它变得丑陋。我必须在其中制作一个新的适配器层，这对我来说似乎不好。
I am getting in the topic of clean architecture and I am struggling how to integrate an external REST API. I would define the interface of the API in the application layer and put the implementation into the infrastructure layer.
But where to store the DTOs/models of the external api?
Do I have to create a mapping so that I do not store the models in the core layer? This seems to me the correct approach but then it gets ugly when I try to use the nswag to generate the client. I kind of have to make a new adapter layer in between which seems not nice to me.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一种技术是将外部API DTO作为数据层处理。该概念与与数据库交谈的概念相同，只是它提出了HTTP请求。这将使您可以将API的实现详细信息交换为也许是总线或直接DB呼叫。在我从事的一个项目中，我们将所有外部API调用放入DAL中，并像其他任何数据访问调用一样对待它。因为，毕竟只是数据，并且应用程序中的客户面对实体可能无法正确表达。
One technique is to treat the external API DTOs like a data layer. The concept is the same as talking to a database except it is making an HTTP request. This will allow you to swap implementation details from say an API to maybe a bus or direct DB call. In one project I worked on, we put all external API calls in the DAL, and treated it just like any other data access call. Because, after all it is just data and may not be expressed correctly by the customer facing Entity in the app.