需要帮助规划体系结构的分类难题

时间:2010-10-29 05:17:50

标签: oop design-patterns information-architecture

我有更多的“你想做什么”的问题,而不是实际的编码问题。 它涉及我目前正在进行的项目。在这个项目中, 我们的任务是将多个市场API组合到一个界面中。每 API有自己独特的产品分类方式。顶级 我们正在查看的所有API的父类别都或多或少 同样有一些变化。但是,子类别是疯狂的 不同。

例如,一个API需要长的面包碎屑痕迹 选择一个类别,例如:体育>球类运动>新英格兰> 足球>活跃团队>爱国者>大事记。而另一个API有两个级别 分类:体育>爱国者大事记。在许多情况下,有子类别 与任何API的子类别无关。

所以,问题是 - 设计时最好的方法是什么 界面?我们目前正在两种可能性之间挣扎:

1)在客户端上设计自定义类别UI,然后构建逻辑 能够对各种API的需求进行排序的服务器 基于用户选择的选择。

2)以用户必须遍历的方式创建UI 每个API的必要步骤。根据用户设置,这意味着 他可能需要填写API特定信息5,6,10或更多 次。

虽然我被告知第一个选项是一个真正的编程噩梦( 示例我给出的是更改API数据字段)我强烈认为第二个选项会惹恼客户。

有任何想法吗?

3 个答案:

答案 0 :(得分:2)

这是一个非常难的问题。如果您搜索“本体产品分类”,您会找到许多关于该主题的研究论文和讨论。如果一个只是另一个的更详细的版本,那将是非常可行的,但是你的描述暗示情况并非如此,因此你需要构建自己的分类方案并将其他方案映射到它上面。

您是否拥有可以验证不同产品类别之间映射的公用密钥(UPC代码?或其他)?如果是这样,您可以构建自己的分类方案,然后将其他分类方案映射到它上,并取得一定程度的成功。

显然,第一个选项对消费者来说是最好的,但构建这样的映射可能非常困难且非常耗时,并且需要不断更新。

一种方法是构建比任何提供的层次结构更简单的层次结构。一个更简单的层次结构将使得将类别映射到层次结构中的[主要是手动]工作变得更加容易,因为大多数只是包含。这可能会使用户体验变得更糟,但如果你添加了很棒的搜索功能和优秀的“相关产品”/“购买此产品的人也购买了这个”工具围绕产品浏览体验,你可以弥补缺乏层次结构。

答案 1 :(得分:1)

头号并不是一场噩梦。您的用户体验是第一要务;永远别忘了。如果用户可以更轻松地浏览较短的路线,那么请给他们机会。另外,我会用一些抽象包装API,所以我的代码根本不知道API,只知道抽象层。通过这种方式,我可以更改API并保留大部分代码,只更改抽象层。

使用会话将数据从一个页面传递到另一个页面,并使用工厂根据会话数据创建页面的状态;这将加强页面,状态和用户数据之间的上下文。

在页面的上下文中保留第一级对象(页面直接对话的对象);这有助于诊断问题。

最重要的是,为您的抽象层创建一系列测试,测试每个对象,函数和输入输出对,以确保您的应用程序坚如磐石。

答案 2 :(得分:0)

您必须为您的客户提供一致且不变的界面。

我想看一个你想到的两种不同方法的例子。

API.find( PRODUCT, CATEGORIES_LIST )