我試圖找出設計以下場景的最佳方法。
讓我們假設，我已經有了一個REST API實作，它將從不同的提供者那里獲取書籍并將它們提供給我自己的客戶。
- 每個提供者都提供一個單獨
API的服務來向其消費者提供圖書。 - 每個提供者的回應結構與前一個完全不同。
- 我的客戶端應該始終獲得完全相同的格式，以便前端客戶端應用程式可以處理回應。
一些輸出示例：
提供者 1
[
{
"bookId": 32,
"bookName": "foo",
"author" : {
"name" : "John",
"surname": "Doe"
},
"publisher": {
"name" : "Foo Books",
"address": "New York"
}
},
...
]
提供者 2
[
{
"publisherCompany": {
"name": "Foo Books",
"position": "New York",
"books": [
{
"id": 32,
"title": "Foo",
"author": {
"name" : "John",
"lastName": "Doe"
}
},
...
]
}
},
...
]
這兩個提供程式都輸出相同的值，但格式不同。而且有些鍵是完全不同的。
我正在尋找的是架構設計或設計模式，因此我可以將每個不同的輸出映射到我自己的格式。
我過去嘗試過的
- 我創建了自己的物體
- 我為每個消費者提供不同的服務，在獲取資料后，我正在實體化我自己的物體并相應地映射回應。
- 在我的物件（物體）填充資料之后，我將它們傳遞給一個轉換器函式以將它們轉換為所需的輸出。
我的問題：
- 有什么
Design Pattern辦法嗎？ - 這種情況是否有任何術語，以便我可以進行研究？
- 您會以何種方式處理這種情況？
- 有什么閱讀資源嗎？
謝謝 ;）
uj5u.com熱心網友回復：
并非所有東西都必須遵循設計模式或名稱，只需使用您的知識和常識即可。
在這種情況下，您想要的是以下內容：
- 擁有您自己的域模型和一個服務層，可以從您的所有提供者那里獲取資料。
- 為提供者 1 模型和一個特定的服務層有一個特定的模型來處理對提供者 1 的呼叫和到您自己的域模型的映射。
- 有一個特定的 Provider 2 模型和一個特定的服務層來處理對 Provider 2 的呼叫和到您自己的域模型的映射。
與提供者 1 和 2 相關的服務都應實作相同的介面，該介面指定您可能需要的其他提供者服務的合同。這將是您的域服務層將知道和使用的介面。
這或多或少是你已經擁有的，但如果你想給它起個名字，你可以閱讀六邊形架構，它與所描述的解決方案有一些相似之處。我推薦以下文章：
- https://medium.com/ssense-tech/hexagonal-architecture-there-are-always-two-sides-to-every-story-bc0780ed7d9c
- https://reflectoring.io/spring-hexagonal/
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/337384.html