例如，在电子商务网站中，我们通常有两个界面。一种与客户互动并下订单，另一种与公司员工互动以管理订单和客户等。
如果我们把这个网站分成两个不同的网站。这意味着，两个不同的项目都在一起，不相互依赖。两个网站之间唯一的共同点就是数据库。两个网站将使用相同的数据库。那么什么是制作数据访问层
的好选择在我看来，第二种选择会更好。由于它取消了对数据库的依赖，因此对数据库所做的任何更改都不需要在两个地方进行。还有许多其他好处。
但我唯一担心的是，它会在多大程度上影响整个系统的性能？因为在这种情况下，我们正在序列化和反序列化对象，并使用 HTTP 连接。
与拥有自己的数据库访问代码相比，是否有人可以说明 API 支持的数据访问层的优点和缺点。
【问题讨论】：
标签： json database api data-access-layer
人们不同意此类事情的最佳架构，但一个常见且流行的架构指南建议您不惜一切代价避免在数据库层集成两个产品。拥有两个可以相互独立更改的独立应用程序和数据库更简单，如果您需要从一个引用另一个数据，您应该在 esb 上配置两者之间的某种事件管道。
而且，无论如何，您可能应该有两个以上的后端数据库——除非您有一个非常简单的系统，其中只有您提到的两类对象，否则您可能会发现您有两个以上的有界域。
另外，如果您的性能要求增加，那么您可能希望考虑拆分服务和数据库的读取和写入端，通过某种事件系统（可能是事件溯源）将两端连接起来。
在你决定做什么之前，你应该阅读Implementing Domain Driven Design by Vaughn Vernon。还有，CQRS by Martin Fowler 上的论文。还有event sourcing, also from Dr Fowler 上的论文。如需加分，您还应该阅读Fowler on Microservices architecture。
最后，在 JSON 上——我是它的忠实粉丝——但如果你在后端使用 javascript，你应该只在存储库界面使用它（如果你正在使用，这是一个好主意io.js 和 Koa）和前端（请backbone 和marionette），或者如果您使用的是本机发出 json 的数据源。如果您必须解析它，那么它只会减慢您的速度，因此请使用数据源及其消费者原生的某种格式，这样您将尽可能快。
【讨论】：
以 API 为中心的方法更有意义，因为数据已标准化，并且可以在任何语言中用于一个或多个接口，从而为您提供更大的灵活性。
性能方面，这在很大程度上取决于 API 背后技术堆栈的质量和实施。您还可以考虑在前端缓存某些数据以缩短页面加载时间。
moltin 的人已经建立了这样的平台，我在使用它方面取得了巨大的成功。已经有一个后端仪表板，响应时间也很快！
【讨论】：