将后端应用程序和前端web应用程序完全解耦并允许它们与(JSON) REST通信是正常的设计吗？
我正在创建新的商业web应用程序，我想实现：
- 使用各自领域中最好的技术。我想要可靠的后端框架与坚实的ORM。我希望使用最先进的SPA (单页应用程序)框架，为前端应用程序使用最新的HTML和Javascript特性。
- 公开后端实体和业务服务，供不同类型的应用程序使用--例如web应用程序、移动(Android)以及其他类型(智能设备等)。
因此，为了满足这两种需求，我倾向于将我的应用程序完全分离在后端和前端应用程序中，并使用REST (JSON)组织它们之间的通信。这是正确的方法吗？
这种分离不是明显的设计解决方案，因为许多web应用程序技术都集成了视图层，服务器端应用程序或多或少控制了视图的生成，并且部分地处理来自视图的响应(例如，带有视图层的SpringMVC、带有视图层的PHP、完全保存其组件在服务器上的状态的Java /Facelets)。因此，有许多技术提出了更强的耦合，并承诺更快的开发时间和更标准的路径旅程。因此，当我开始以不被广泛使用的方式使用技术时，我必须谨慎。
据我所知，完全分离的SPA前端通常来自于使用第三方API的必要性。但是，当后端和前端都由一家公司开发时，这种脱钩的设计是否合理呢？
如果允许我这样说的话，我目前选择的技术是Java/Spring后端和Angular2 2/Web组件/聚合物。但这与这个问题无关，因为这个问题是关于一般的设计，而不是关于具体技术的选择？
回答 2
Software Engineering用户
发布于 2016-12-05 08:22:36
你问题的答案很简单。是。你所建议的是一种合理的方法。但是，我想你想问的是，这是否是一个更好的方法，不幸的是，我们没有人能为你回答这个问题。所涉及的因素涉及太多的方面，如果不透露关于组织和产品需求的所有信息，就无法得出真正的结论。我想你已经知道该怎么做了。
Software Engineering用户
发布于 2016-12-04 15:07:46
有警告的正常人。
前端javascript框架所能做的是有限的。如果您创建了供多个应用程序使用的原始api，它们通常需要一些服务器端处理原始api调用到使用该特定应用程序的视图模型中。
因此，“正常”架构可能是：
database
business logic services (dll)
api exposing business logic
server side website exposing viewmodels and functionality via json rest endpoints
client side javascript implementing ui现在，如果您只有一个web应用程序，则可以删除'api公开业务逻辑‘层，并让服务器端web代码直接调用业务逻辑。
因为您已经将业务逻辑分离到它自己的库中，它仍然与ui逻辑分离，您以后总是可以添加一个服务层。
类似地，由于api服务是由服务器端代码调用的，所以您不受http通信的限制。(虽然现在这是相当普遍的做法)
此外，让javascript调用它所服务的同一个主机意味着您不必在cors中胡闹。
https://softwareengineering.stackexchange.com/questions/337467
复制相似问题
腾讯云开发者
