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

Question

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

以下是我们需要支持的不同前端演示级别的示例：

• 面向消费者的传统桌面网站
• 针对消费者的移动优化网站
• 供消费者使用的原生移动应用程序（iOS / Android）
• 客户支持中心客户支持代表网站
• 基于Instore kiosk的网站，供消费者在实体店购物
• 其他（微型网站和其他利用各种技术，如Angular，PHP，.NET等）

现在，我了解了分层架构（演示，业务，数据层）和常见设计模式的最佳实践，以解决单个应用程序（如MVC，验证器，拦截器）中的前端挑战。但是，这些原则都不能解释 和 ，以便在面对支持时最好地封装您的演示文稿特定业务逻辑多个前端。

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

我在过去使用不同的方法开发了许多具有这种要求的应用程序......其中一些工作得相当好，一些工作效果不是很好。但每次我觉得我正在为一个共同的问题发明一个解决方案，并且必须有一些最好的实践和原则来利用。

我询问的具体挑战的一个简单例子

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

• 电子邮件地址模式验证规则
• 确保系统中不存在电子邮件地址
• 密码复杂性规则
• 地址验证（通过第三方地址验证/标准化系统）

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

为了清楚起见，我并不关心在哪里放置所有前端共享的核心业务逻辑（即帐户创建服务，地址验证服务，帐户查找服务等）。这些模式通常在博客，书籍和论坛中讨论。我的问题与业务逻辑特别相关，业务逻辑通常与表示层紧密耦合。有些问题总是浮现在我的脑海中。

• 我们是否应该提供 演示服务层 ，它支持所有前端操作，包括表单验证和通过Web服务处理？或者每个前端是否应该拥有它的表示逻辑，因为“没有两个前端相似”？
• 如果我们确实创建 演示文稿服务层 ，我们如何提供解决每个前端细微差异的服务？我们是否为每个前端提供不同的服务/端点，或者只是提供每个前端在调用我们的服务时传递的不同“上下文”？
• 此演示服务层是否控制错误消息传递并向每个前端返回适当的上下文感知消息，或者我们是否应该传回错误代码并让前端拥有此消息？
• 等

Answer 1

没有一种神奇的方法可以在所有前端中具有一致的验证规则，尤其是当您混合使用不同的技术和环境（PHP，JS，本机应用程序）时。如果您的验证规则很复杂，则实现它的代码将始终很复杂。

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

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

Answer 2

如果我理解你的问题，我会这样做：

使用Strategy pattern根据抽象实现每个演示文稿。使用Factory来实例化您的具体策略。使用MVC分隔您的层，并使用Observer更新您的视图层中的策略。

希望它有所帮助。