design-patterns - 如何避免跨多个不同的表示层复制业务逻辑

Question

我目前正在为一个多 channel 商务系统设计架构，该系统将有多个不同的前端展示，这些展示是针对设备和 channel (用户类型和位置)量身定制的。我面临的挑战是如何最好地确保我们以减少前端表示层重复的方式开发核心商务平台。

以下是我们需要支持的不同前端演示层的示例:

面向消费者的传统桌面网站

面向消费者的移动优化网站

面向消费者的本地移动应用程序 (iOS/Android)

面向客户支持代表的客户支持中心网站

面向在实体店购物的消费者的店内售货亭网站

其他(微型网站和其他利用各种技术，如 Angular、PHP、.NET 等)

现在，我了解了围绕分层架构(表示层、业务层、数据层)和常见设计模式的最佳实践，以解决单个应用程序(例如 MVC、验证器、拦截器)中的前端挑战。然而，这些原则都没有解释 怎么样和 哪里在面对支持多个前端时最好地封装您的演示文稿特定的业务逻辑。

所以，我的问题是 在开发这样的系统以确保每个前端应用程序不会重复前端业务逻辑时，应遵循哪些良好实践和原则？

过去，我使用不同的方法开发了许多具有此类要求的应用程序……其中一些工作得很好，而另一些工作得不太好。但每次我都觉得我是在为一个常见问题发明一个解决方案，并且必须有一些最佳实践和原则可以利用。

我所询问的具体挑战的快速示例

我们所有的前端应用程序都必须支持注册新客户帐户的能力。注册表将包含电子邮件、密码和客户地址信息(街道、城市、邮政编码等)等信息。提交表单时，在系统中创建帐户并向用户发送验证电子邮件之前，需要进行某些重要和重要的验证。例如:

电子邮件地址模式验证规则

确保系统中不存在电子邮件地址

密码复杂性规则

地址验证(通过第三方地址验证/标准化系统)

大多数情况下，这些验证规则需要在所有前端系统中强制执行，尽管每个前端的注册流程可能略有不同，并且可能只包含字段的子集。那么，向前端提供 API 以便每个前端不会重复正确验证和处理注册所需的各个步骤有哪些好的做法？例如，如果我们决定更改密码复杂性规则或地址验证规则等 - 我们如何最好地设计系统，以便我们不必外出并使用这种新的验证逻辑更改所有各种前端应用程序。

明确地说，我不关心将所有前端共享的核心业务逻辑放在哪里(即帐户创建服务、地址验证服务、帐户查找服务等)。这些模式通常在博客、书籍和论坛中讨论。我的问题与通常与表示层紧密耦合的业务逻辑有关。一些问题总是出现在我的脑海中。

我们应该提供一个 表示服务层它支持所有前端操作，包括表单验证和通过 Web 服务进行处理？或者每个前端都应该拥有它的表示逻辑，因为“没有两个前端是相同的”？

如果我们确实创建了一个 表示服务层 ，我们如何提供解决每个前端细微差异的服务？我们是为每个前端提供不同的服务/端点，还是只是提供每个前端在调用我们的服务时传递的不同“上下文”？

这个表示服务层是控制错误消息并将适当的上下文感知消息返回给每个前端，还是我们应该只传回错误代码并让前端拥有它？

等

Answer 1

没有什么神奇的方法可以在您的所有前端中使用一致的验证规则，尤其是当您混合不同的技术和环境(PHP、JS、 native 应用程序)时。如果您的验证规则很复杂，那么实现它的代码总是很复杂。

您可以做的是使您的验证成为核心功能。您可以摆脱表示层中的所有验证，并将其移动到所有前端使用的通用应用程序层。这样，您的演示文稿将只有一个表单并将其发送到服务器以在用户填写表单时获取验证错误。这可以使用来自 Web 的 AJAX 或来自 native 应用程序的 REST API 调用来完成。如果做得好，用户体验不会受到影响。

在这种情况下总是有一个权衡:您将花费更少的时间来维护验证代码，但代价是响应性和/或用户体验稍差。