[英]How to avoid duplicating business logic across multiple different presentation layers
I am currently designing the architecture for an multi-channel commerce system which will have multiple different frontend presentations which are tailored to device and channel (user type and location). 我目前正在为多渠道商务系统设计架构,该系统将具有针对设备和频道(用户类型和位置)定制的多个不同的前端演示。 The challenge I'm facing is how to best ensure we are developing the core commerce platform in a way that reduces duplication in the frontend presentation tiers.
我面临的挑战是如何最好地确保我们以减少前端表示层重复的方式开发核心商务平台。
Here is a sampling of the different frontend presentations tiers we will need to support: 以下是我们需要支持的不同前端演示层的示例:
Now, I know the best practices around a layered architectures (presentation, business, data tiers) and common design patterns to address frontend challenges within a single app (such as MVC, validators, interceptors). 现在,我了解了分层体系结构(表示,业务,数据层)和常见设计模式的最佳实践,以解决单个应用程序(如MVC,验证器,拦截器)中的前端挑战。 However, none of these principles explain how and where to best encapsulate your presentation specific business logic when faced with supporting multiple frontends.
但是,这些原则都没有解释在面对支持多个前端时如何以及在何处最佳地封装您的表示特定业务逻辑。
So, my question is what are some good practices and principles to follow when developing such a system to ensure each frontend application is not duplicating frontend business logic? 所以,我的问题是在开发这样一个系统时要遵循一些好的做法和原则,以确保每个前端应用程序不会重复前端业务逻辑?
I have developed many applications with requirements like this in the past using different approaches...some of which worked fairly well and some which worked not so great. 我过去使用不同的方法开发了许多具有这种要求的应用程序......其中一些工作得相当好,一些工作效果不是很好。 But each time I felt like I was inventing a solution for a common problem and that there must be some best practices and principles to leverage.
但每次我觉得我正在为一个普通问题发明一个解决方案,并且必须有一些最好的实践和原则来利用。
All of our frontend applications must support the ability to register a new customer account. 我们所有的前端应用程序都必须支持注册新客户帐户的能力。 The registration form will take in information such as email, password, and customer address information (street, city, zip, etc).
登记表格将包含电子邮件,密码和客户地址信息(街道,城市,邮编等)。 When the form is submitted there will be certain trivial and non-trivial validations that need to occur before the account is created in the system and a verification email is sent to the user.
提交表单时,在系统中创建帐户并向用户发送验证电子邮件之前,需要进行某些简单且非平凡的验证。 For example:
例如:
For the most part, these validations rules need to be enforced across all frontend systems, though each frontend's registration flow might be slightly different and might only contain a subset of the fields. 在大多数情况下,需要在所有前端系统中强制执行这些验证规则,尽管每个前端的注册流可能略有不同,并且可能只包含字段的子集。 So, what are some good practices to provide an API to the frontends such that each frontend does not duplicate the various steps required to properly validate and process the registration?
那么,为前端提供API的一些好的做法是什么,这样每个前端都不会复制正确验证和处理注册所需的各个步骤? For example, if we decide to change the password complexity rules or address validation rules, etc - how, might we best design the system such that we will not have to go out and change all the various frontend applications with this new validation logic.
例如,如果我们决定更改密码复杂性规则或地址验证规则等 - 我们是否可以最好地设计系统,以便我们不必走出去并使用这个新的验证逻辑更改所有各种前端应用程序。
Just to be clear, I'm not concerned about where to put core business logic which is shared across all frontends (ie account creation services, address validation services, account lookup services, etc). 为了清楚起见,我并不关心在哪里放置所有前端共享的核心业务逻辑(即帐户创建服务,地址验证服务,帐户查找服务等)。 Those patterns are commonly discussed in blogs, books, and forums.
这些模式通常在博客,书籍和论坛中讨论。 My questions are specifically related to the business logic which is commonly tightly coupled to the presentation tier.
我的问题与业务逻辑特别相关,业务逻辑通常与表示层紧密耦合。 Some questions that always come to my head.
一些问题总是浮现在我的脑海中。
There is no magic way of having consistent validation rules across all of yours frontends, especially if you're mixing different technologies and environments (PHP, JS, native apps). 没有任何神奇的方法可以在所有前端拥有一致的验证规则,特别是如果您混合使用不同的技术和环境(PHP,JS,本机应用程序)。 If your validation rules are complex, the code implementing it will always be complex.
如果您的验证规则很复杂,那么实现它的代码将始终很复杂。
What you can do is to make your validation a core functionality. 您可以做的是使您的验证成为核心功能。 You can get rid of all validation in the presentation layers and move it to the common application layer used by all frontends.
您可以摆脱表示层中的所有验证,并将其移动到所有前端使用的公共应用程序层。 This way your presentation will just a have a form and send it to the server to get validation errors while the user is filling the form.
这样,您的演示文稿将只有一个表单并将其发送到服务器以在用户填写表单时获得验证错误。 This could be done using AJAX from web or REST API call from native app.
这可以使用来自web的AJAX或来自本机应用程序的REST API调用来完成。 If done right user experience won't be compromised.
如果做得对,用户体验不会受到影响。
There is always a trade off in such cases: you'll spend less time on maintaining the validation code at the cost of slightly worse responsivenes and/or user experience. 在这种情况下总是存在折衷:您将花费更少的时间来维护验证代码,但代价是响应性和/或用户体验稍差。
If I understood your question properly, I'd do like this: 如果我理解你的问题,我会这样做:
Use the Strategy pattern to implement each of presentations according to the abstraction. 使用策略模式根据抽象实现每个演示。 Use a Factory to instantiate your concrete strategies.
使用工厂来实例化您的具体策略。 Use MVC to separate your tiers, and use Observer to update your strategies in your view layer.
使用MVC分隔您的层,并使用Observer更新视图层中的策略。
Hope it helps. 希望能帮助到你。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.