小编zmc*_*hon的帖子

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

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

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

现在,我了解了分层体系结构(表示,业务,数据层)和常见设计模式的最佳实践,以解决单个应用程序(如MVC,验证器,拦截器)中的前端挑战.但是,这些原则都没有解释在面对支持多个前端时如何以及在何处最佳地封装您的表示特定业务逻辑.

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

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

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

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

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

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

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

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