Question

我的工作场所有一个非常难看的遗留数据库。请注意，我不是数据库方面的专家，但有些事情看起来很奇怪。例如，看到如下表格是很常见的。

Zuser
  zuserid
  shoerdesc
  description
  virtualattributes
  birthdate1
  birthdate2
  qa_bookstoreid

我们最近推出了一个“假定的”REST API，它充当数据库中几个表的转储。最终用户最终会获得具有空值的数据字段，难以解释的数据以及大量垃圾。

API示例：

{
  "last_updated" : "2010/10/10",
  "details" : {
    "zuserid"   : "b5b4546b3b33b",
    "birthday1" : "1980/10/10",
    "birthday2" : "1980/10/10",
    "zaccess"   : null,
    "zwebsite"  : null,
    ..
  }
}

为了使API能够与实际使用它的单个客户端一起工作，我们不得不经历相当多的手持操作，告诉他们向最终用户展示什么等等。

好消息是上层人士表示有兴趣在未来使API更通用，更易于使用。我已经开始寻找这种情况的良好实践，但我的数据库经验非常有限，我不知道在哪里看。（我主要是一名软件/网络工程师。）

我主要研究DataMapper模式（我们使用ActiveRecord和Rails）。它似乎做了很多工作，但我仍然不确定是否最好在应用程序级别进行映射，或者创建一个新应用程序，在新数据库中进行映射并以某种方式同步这两个。

关于什么是一个好的解决方案的任何想法？最好是不会破坏现有数据库的东西。请注意，我在“corpochain”中相当低，因此大多数决策都是由其他人做出的。

Answer 1

根据我的经验，任何好的REST api都需要相当多的映射到它的域模型。否则，API会泄漏内部域，或者内部域最终会在API之后建模 - 两种方法都远非理想。

我的建议是，将您的API完全与您的域模型分开，这样您就可以在不影响另一个的情况下进化。有些人向前迈进了一步，将域模型与持久性实体分开（Robert C. Martin强烈支持这一点......甚至在Rails中）。

如果您做出这个决定，那么您就可以开始考虑我们的客户想要的API是什么？使其易于使用，一致且与您的客户相关（如您所述，手持是一个不明确的API的症状。）

丑陋数据库的API

1 个答案: