39、应用用户界面设计原则与多模态客户端架构-优快云博客

本文链接：https://blog.youkuaiyun.com/php55/article/details/154172060

应用用户界面设计原则与多模态客户端架构

1. 应用用户界面设计原则

在设计应用程序时，将不同用途的适配器围绕应用核心的概念体现了一个关键理念，即不同的用户界面（UI）风格应与所依赖的业务逻辑分离。在端口和适配器架构中，它们都可视为“适配器”。以下是客户端架构的一些基本原则：
1. 分离展示逻辑与业务逻辑 ：确保展示层和业务层的独立性，便于维护和扩展。
2. 提供一致视图 ：无论用户如何与应用交互，都能获得一致的视图。理想情况下，这种一致性应由应用的领域服务支持，这可能需要明确对用户进行建模。
3. 适配用户需求 ：认识到用户具有多样性，交互方式也不尽相同。因此，应用逻辑应能通过多种形式因素和渠道访问。
4. 支持端到端开发 ：开发团队应负责用户交互的前端和后端部分，包括用户体验和实现业务流程的域服务。

这些原则有助于设计出可通过多种用户界面访问的应用程序。

2. 多模态客户端应用架构模式

这些模式之间的关系可以用以下 mermaid 流程图表示：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(客户端应用):::process --> B(浏览器应用):::process
    A --> C(移动应用):::process
    A --> D(命令行界面):::process
    A --> E(公共API):::process
    A --> F(交互模型):::process
    B --> B1(网页表单应用):::process
    B --> B2(单页应用):::process
    B --> B3(微前端):::process

3. 客户端应用（Client Application）

3.1 问题提出

当开发了一个云应用（可能采用云原生架构或微服务）后，用户需要访问该云应用的服务。但云应用运行在云端，不在用户的桌面计算机、浏览器、手机或平板电脑上，这给用户访问带来了挑战。

3.2 解决方案

开发一个客户端应用，让用户在自己的计算机或设备上运行该客户端应用，并通过网络（如互联网）连接到云应用。客户端/服务器应用架构解决了这个问题，它将单体应用拆分为客户端和服务器两部分。在云计算中，服务器是云端的计算基础设施，客户端应用运行在用户设备上，通过网络与云应用交互。

3.3 特点与优势

多客户端支持 ：一个云应用可以有多个针对不同用户角色和客户端计算机架构的客户端应用，以提供不同的功能子集或适配不同设备。
独立开发与稳定接口 ：客户端应用应通过服务API与云应用交互，API保持稳定，使客户端和云应用能够独立演进。同一开发团队应负责客户端、API和调度器的实现。

3.4 常见类型

浏览器应用 ：在用户客户端计算机或设备的HTML网页浏览器中运行。
移动应用 ：在客户端智能手机或平板电脑上运行。
命令行界面 ：在客户端计算机或设备的操作系统外壳中运行，提供调用服务器功能的命令。

3.5 示例

网站：电子商务、银行、旅游等交互式网站通常连接到云端的后端。企业内部应用也常通过网页浏览器访问云端后端。
移动应用 ：智能手机或平板电脑上的应用大多依赖网络连接，将主要工作委托给云端服务器。
命令行界面（CLI） ：开发者常用CLI管理基础设施和服务，许多云平台支持通过CLI创建和管理整个环境。

4. 浏览器应用（Browser Application）

4.1 问题提出

在构建云应用时，需要一个简单、通用的客户端应用，不依赖特定的硬件或软件配置。

4.2 解决方案

开发一个浏览器应用，可在任何HTML网页浏览器中运行。实际上，最简单形式的浏览器应用并非在浏览器中运行，而是通过用户浏览器在互联网上访问的动态网站。

4.3 工作原理

远程服务器上的程序监听特定URL的HTTP请求，并根据请求生成相应的HTML网页进行响应。服务器可以返回多种内容类型，如HTML、图像、CSS、JavaScript和JSON等。

4.4 优缺点

优点

通用性强 ：几乎所有具有HTML网页浏览器的计算机或设备都能运行。
无需安装 ：完全在浏览器中运行，访问网站即可使用。
轻量级 ：对客户端内存要求低，适合低带宽网络连接。

缺点

设备特性利用不足 ：不如移动应用能充分利用设备的独特功能（如相机、GPS等）。
扩展性有限 ：第三方扩展不如公共API或命令行界面方便。

4.5 发展形式

随着Web技术的发展，浏览器应用有以下几种形式：
| 形式 | 描述 |
| — | — |
| 网页表单应用 | 由服务器端渲染的HTML页面构建，无JavaScript，页面过渡通过链接或表单提交触发。 |
| 单页应用 | 由多个HTML片段在同一网页中动态组装和渲染，使用JavaScript和CSS在客户端构建。 |
| 微前端 | 可通过框架组合成单页应用的小型应用。 |

4.6 发展历程示例

CGI（Common Gateway Interface） ：HTML 1.0发布后不久出现，通过外部程序使网站动态化。部分页面由Web服务器提供，部分通过特殊目录委托给外部程序生成动态页面。
模板应用与PHP ：将生成HTML和动态内容的程序集成到单个模板机制中，PHP是典型代表。PHP代码嵌入HTML页面，由Web服务器动态解释和评估。
ASP.NET、Servlet和JSP ：开发者意识到将HTML模板作为请求目标不利于页面选择，因此将请求处理器与模板引擎分离。在ASP.NET和Java Enterprise Edition中，请求处理器（如Java Servlet）与Java Server Page（JSP）分离。
JavaScript和AJAX ：1995 - 1997年，JavaScript引入浏览器。2006年，Internet Explorer引入新功能，允许JavaScript应用调用后端系统，AJAX成为Web应用新方法的基石。

5. 网页表单应用（Web Form Applications）

5.1 基本概念

网页表单应用是最古老的浏览器应用类型之一，至今仍是小型、简单应用的默认选择。它结合了服务器端渲染（使用模板语言）和基于简单表单的导航方式。这种应用适合在硬件条件不太理想的平台上与用户进行交互，对用户端的要求较低，只需在浏览器中打开URL即可。

5.2 工作流程

其工作流程可以用以下 mermaid 流程图表示：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(用户在浏览器打开URL):::process --> B(服务器接收请求):::process
    B --> C(服务器使用模板语言渲染HTML页面):::process
    C --> D(服务器返回HTML页面给浏览器):::process
    D --> E(用户在页面填写表单并提交):::process
    E --> F(服务器接收表单数据):::process
    F --> G(服务器处理数据并更新页面):::process
    G --> H(服务器返回更新后的HTML页面给浏览器):::process

5.3 优缺点

优点

简单易用 ：开发和维护相对简单，对于小型应用来说，不需要复杂的前端技术。
兼容性好 ：可以在各种浏览器和设备上正常显示，对硬件和软件环境的要求较低。
安全性高 ：由于大部分逻辑在服务器端处理，减少了客户端的安全风险。

缺点

交互性差 ：页面的更新需要刷新整个页面，用户体验不够流畅。
开发效率低 ：服务器端渲染需要每次请求都重新生成页面，增加了服务器的负担，开发效率相对较低。

6. 单页应用（Single - Page Applications）

6.1 基本概念

单页应用是构建复杂客户端Web应用的常见方法，它充分利用了现代浏览器的强大功能。这种应用通过浏览器中的JavaScript、CSS和HTML技术，在客户端动态地加载和渲染页面内容，提供高度交互的用户体验。

6.2 工作原理

单页应用的工作原理可以概括为以下几个步骤：
1. 初始加载 ：用户打开应用时，浏览器加载一个包含基本HTML结构和必要脚本的初始页面。
2. 数据请求 ：通过JavaScript代码向服务器发送异步请求，获取所需的数据。
3. 动态渲染 ：使用JavaScript和CSS将获取的数据动态地渲染到页面上，实现页面内容的更新。
4. 路由管理 ：通过前端路由机制，实现页面之间的切换，而不需要刷新整个页面。

6.3 优缺点

优点

交互性强 ：页面的更新无需刷新整个页面，用户体验流畅，响应速度快。
开发效率高 ：前端和后端可以独立开发和部署，提高了开发效率。
代码复用性高 ：可以将页面的不同部分封装成组件，实现代码的复用。

缺点

首屏加载慢 ：由于需要加载大量的JavaScript和CSS文件，首屏加载时间可能较长。
搜索引擎优化困难 ：由于页面内容是动态生成的，搜索引擎难以抓取和索引，不利于SEO。
安全性问题 ：由于大部分逻辑在客户端处理，增加了客户端的安全风险。

7. 微前端（Micro Frontends）

7.1 基本概念

微前端是一种避免在使用单页应用架构构建的客户端应用中重蹈单体应用覆辙的方法。它将大型前端应用拆分成多个小型、独立的应用（微前端），这些微前端可以独立开发、部署和维护，然后通过一个框架组合成一个完整的单页应用。

7.2 工作模式

微前端的工作模式可以用以下 mermaid 流程图表示：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(主应用加载):::process --> B(加载微前端框架):::process
    B --> C(微前端框架加载微前端应用):::process
    C --> D(微前端应用独立运行):::process
    D --> E(微前端应用与主应用交互):::process

7.3 优缺点

优点

独立开发和部署 ：不同的团队可以独立开发和部署各自负责的微前端，提高了开发效率和灵活性。
技术栈无关 ：每个微前端可以使用不同的技术栈，根据具体需求选择最合适的技术。
可维护性强 ：由于微前端的规模较小，代码的可维护性和可测试性更高。

缺点

集成复杂度高 ：将多个微前端组合成一个完整的应用需要解决很多集成问题，如通信、路由、样式冲突等。
性能开销大 ：多个微前端的加载和运行会增加页面的性能开销，需要进行优化。

8. 移动应用（Mobile Application）

8.1 基本概念

移动应用是面向消费者的客户端应用中最具可定制性的解决方案。与Web应用相比，移动应用可以更好地利用移动设备的独特功能，如相机、GPS、传感器等，提供更加个性化和丰富的用户体验。

8.2 开发方式

8.3 优缺点

优点

用户体验好 ：可以充分利用移动设备的硬件特性，提供更加流畅、便捷的用户体验。
功能丰富 ：可以实现更多的功能，如离线使用、推送通知、支付等。
用户粘性高 ：用户可以将应用安装在设备上，方便随时使用，提高了用户的粘性。

缺点

开发成本高 ：需要针对不同的平台进行开发和维护，开发成本较高。
更新不及时 ：应用的更新需要用户手动下载和安装，更新不及时可能会影响用户体验。

9. 命令行界面（Command - Line Interface）

9.1 基本概念

命令行界面允许用户在操作系统命令行与应用进行交互。它是一种简单而强大的交互方式，对于一些简单的自动化操作，在操作系统命令行上执行比通过其他机制更加方便。

9.2 应用场景

命令行界面的应用场景主要包括以下几个方面：
- 系统管理 ：开发者和系统管理员可以使用命令行界面来管理服务器、网络设备等。
- 自动化脚本 ：可以编写脚本文件，通过命令行界面自动执行一系列操作，提高工作效率。
- 调试和测试 ：在开发过程中，可以使用命令行界面来调试和测试应用程序。

9.3 优缺点

优点

高效性 ：可以快速执行命令，完成复杂的操作，提高工作效率。
灵活性 ：可以根据需要自定义命令和脚本，满足不同的需求。
可自动化 ：可以编写脚本文件，实现自动化操作，减少人工干预。

缺点

学习成本高 ：需要用户掌握一定的命令和语法，学习成本较高。
交互性差 ：命令行界面的交互方式相对单一，不够直观，对于普通用户来说不太友好。

10. 公共API（Public API）

10.1 基本概念

公共API是使应用服务可供外部开发者使用的机制。它在与第三方交互（如供应商、业务伙伴或政府实体）或构建开发者生态系统方面非常重要。

10.2 设计原则

设计公共API时，需要遵循以下原则：
1. 简洁性 ：API的接口设计应简洁明了，易于理解和使用。
2. 稳定性 ：API的接口应保持稳定，避免频繁变更，以保证第三方开发者的使用体验。
3. 安全性 ：需要对API进行严格的安全控制，防止数据泄露和恶意攻击。
4. 文档完善 ：提供详细的API文档，包括接口说明、参数解释、返回值等，方便开发者使用。