需要幫助規劃體系結構的分類Connundrum

Question

我有更多的「你會怎麼做」的問題比實際的編碼問題。 它涉及到我目前正在進行的一個項目。在這個項目中，我們的任務是將幾個市場API結合到一個接口中。每個 API都有其獨特的產品分類方式。我們正在查看的所有API的頂級 父類別與某些變體相同或多或少都是 。但是，這些子類別與 不同。

例如，一個API需要很長的麪包屑小徑 選擇一個類別，如：體育>球類運動>英格蘭> 足球>活動團隊>愛國者>大事記。而另一個API有兩級 分類：體育>愛國者大事記。在很多情況下，有 子類別不涉及任何其他API的子類別。

所以，問題是 - 設計 接口時採取的最佳方法是什麼？我們是兩種可能性之間目前摔跤：

1）設計的客戶端上的自定義UI類，然後構建邏輯到 ，能夠通過基於用戶選擇的選擇各種API 的需求來排序的服務器。

2）創建用戶界面的方式是用戶必須遍歷每個API的必要步驟。根據用戶設置，這意味着他可能需要填寫特定於API的信息5,6,10或更多 次。

雖然有人告訴我，選擇排名第一的是一個真正的編程噩夢（在 例子中，我給出的API修改數據字段）我強烈感覺到選項二號會激怒客戶。

有沒有想法呢？

Answer 1

第一個並不是那麼糟糕的噩夢。您的用戶體驗是首要任務;永遠別忘了。如果用戶在更短的路線上更容易地導航，那麼給他們這個機會。另外，我會用一些抽象來封裝API，所以我的代碼根本不知道API，只知道抽象層。這樣我就可以更改API並將大部分代碼放在一邊，只是改變抽象層。

使用會話在頁面之間傳遞數據和工廠根據會話數據在條目上創建頁面狀態;這將加強頁面，狀態和用戶數據之間的上下文。

在頁面上下文中保留第一級對象（頁面直接與之對話的對象）;這將有助於診斷問題。

最重要的是，爲您的抽象層創建一系列測試，測試每個對象，函數和輸入輸出對，以確保您的應用程序堅如磐石。

Answer 2

你必須爲你的客戶提供一個不變的界面。

我希望看到你想到的兩種不同方法的例子。

API.find(PRODUCT, CATEGORIES_LIST) 

Answer 3

這是一個非常難的問題。如果您搜索「本體產品分類」，您會發現許多研究論文和關於該主題的討論。如果其中一個只是另一個的更詳細的版本，那麼這將是非常可行的，但是您的描述意味着情況並非如此，因此您需要構建自己的分類方案並將其他人映射到其上。

你有一個共同的密鑰（UPC代碼？或其他），將允許您驗證您的不同產品類別之間的映射？如果是這樣，你可能能夠構建自己的分類方案，然後將其他人映射到一定程度的成功。

很明顯，第一種選擇對於消費者來說是最好的選擇，但構建這樣的映射可能非常困難且非常耗時，並且需要不斷更新。

一種方法是構建一個比任何提供的更簡單的層次結構。更簡單的層次結構將使得將類別映射到您的層次結構中的[大部分是手動]工作變得更容易，因爲大多數情況只是包含內容。這可能會讓用戶體驗變得更糟，但如果您在產品瀏覽體驗中增加了出色的搜索功能和優秀的「相關產品」/「購買此產品的人也購買了這些」工具，那麼您可能會彌補缺乏層次結構。