驾驭闪电时代的 Visualforce：架构师视角
背景与应用场景
大家好，我是 Salesforce 架构师。在今天的 Salesforce 生态中，当我们谈论用户界面（UI）开发时，Lightning Web Components (LWC) 无疑是主角。然而，任何一位经验丰富的架构师都明白，技术选型并非总是非黑即白。Visualforce，作为 Salesforce 平台经典的 UI 框架，尽管已不再是新功能开发的首选，但它在许多场景下依然扮演着不可或缺的角色。从架构师的角度来看，理解 Visualforce 的核心价值、适用边界及其与现代框架的共存策略，是构建稳健、可维护且符合成本效益的 Salesforce 解决方案的关键。
Visualforce 是一个基于标签的标记语言，类似于 HTML，它与 Salesforce 强大的 Apex 控制器紧密结合，遵循经典的 Model-View-Controller (MVC) 架构模式。在 LWC 出现之前，它是构建复杂、定制化用户界面的主要方式。
那么，在“闪电优先”（Lightning First）的今天，我们为何仍需关注 Visualforce？以下是几个关键的应用场景：
1. PDF 文件生成
这是 Visualforce 最具代表性且至今无法被 LWC 原生替代的核心功能。通过在 <apex:page> 标签中设置 renderAs="pdf" 属性，我们可以轻松地将页面内容渲染成 PDF 文件。这对于生成报价单、合同、发票、报告等业务文档至关重要。从架构上讲，这是一个高效、服务器端的解决方案，无需依赖任何外部服务。
2. 复杂的邮件模板
Salesforce 的标准邮件模板功能有限。当需要发送包含复杂业务逻辑、动态表格和精细格式的邮件时，Visualforce 邮件模板是最佳选择。它允许我们使用 Apex 控制器来查询和处理数据，然后通过 Visualforce 标记语言将其动态地呈现在邮件内容中。
3. 维护遗留系统与逐步现代化
在大型企业中，存在大量基于 Visualforce 构建的核心业务应用。将这些应用一次性重构为 LWC 的成本极高且风险巨大。作为架构师，我们常常需要制定分阶段的现代化策略。这包括维护现有的 Visualforce 页面，同时在新功能模块或独立的业务单元中采用 LWC，并通过 Lightning Out 或其他集成方式让新旧组件共存。
4. 特定 Classic 环境下的定制
虽然大多数组织已经迁移到 Lightning Experience (LEX)，但仍有部分用户或特定业务流程停留在 Salesforce Classic。对于这些场景，Visualforce 仍然是进行深度 UI 定制的主要工具。
5. 快速实现简单的、以数据为中心的页面
对于一些简单的 CRUD（创建、读取、更新、删除）操作页面，利用 Visualforce 的标准控制器 (Standard Controller) 可以极大地减少代码量，快速交付功能。标准控制器自动处理数据查询、保存和删除逻辑，并内置了平台的安全和共享规则。
原理说明
要深入理解 Visualforce，就必须掌握其背后的 MVC 架构。这种分层设计确保了数据、业务逻辑和用户界面的分离，使得应用更易于开发、测试和维护。
1. 模型 (Model)
在 Salesforce 中，模型层就是我们的数据结构，主要由 sObjects（Standard Objects and Custom Objects）组成。这包括客户（Account）、联系人（Contact）等标准对象，以及我们为满足特定业务需求创建的自定义对象。模型层定义了数据的字段、类型和关系。
2. 视图 (View)
视图是用户直接交互的界面，也就是 Visualforce 页面本身（以 .vfp 结尾的文件）。它由一系列 <apex:xxx> 标签组成，这些标签在服务器上被解析和处理，最终生成标准的 HTML、CSS 和 JavaScript 发送给浏览器。视图负责展示数据，但不包含复杂的业务逻辑。
3. 控制器 (Controller)
控制器是连接模型和视图的桥梁，它由 Apex 代码编写，负责处理用户的输入、执行业务逻辑、查询或修改数据。Visualforce 中的控制器主要分为三类：
- Standard Controller (标准控制器): Salesforce 为所有标准和自定义 sObject 提供的内置控制器。它提供了基础的 CRUD 功能，并自动处理 FLS（字段级安全）和共享规则，是实现简单数据操作页面的首选。
- Custom Controller (自定义控制器): 完全由开发者编写的 Apex 类。它赋予了开发者完全的控制权，可以实现复杂的业务逻辑、调用外部服务或处理非 sObject 数据。使用自定义控制器时，开发者必须自行负责安全和共享规则的实施。
- Controller Extension (控制器扩展): 一个 Apex 类，用于扩展或覆盖标准控制器或另一个自定义控制器的功能。它允许我们在利用标准控制器便利性的同时，添加自定义的逻辑。一个 Visualforce 页面可以有多个扩展。
请求生命周期与 View State
从架构层面看，理解 Visualforce 的请求生命周期和 View State 至关重要。Visualforce 是一个服务器端 (Server-Side) 渲染框架。
当用户与页面交互时（例如点击一个按钮），整个页面的状态，即 View State，会被加密并序列化后发送到服务器。服务器上的 Apex 控制器接收到请求，执行相应的方法，更新数据。然后，服务器根据最新的数据状态重新渲染整个页面（或通过 AJAX 局部刷新），并将生成的 HTML 返回给浏览器。
View State 是一个隐藏的、加密的表单字段，它保存了页面组件、字段值和控制器状态。它的存在使得页面能够“记住”之前的状态，但也成为了 Visualforce 性能的主要瓶颈。一个过大的 View State 会显著增加请求和响应的负载，导致页面加载缓慢。这是我们在架构设计中必须严格控制的一点。
示例代码
以下示例均来自 Salesforce 官方文档，以确保其准确性和最佳实践。
示例 1: 使用标准控制器显示记录
这个例子展示了如何用最少的代码创建一个显示客户（Account）详细信息的页面。它利用了标准控制器，无需编写任何 Apex 代码。
<!--
Visualforce Page: AccountDetail
Description: Displays details of a single Account record using the standard controller.
-->
<apex:page standardController="Account">
<!--
standardController 属性指定了此页面使用 Account 对象的标准控制器。
Salesforce 平台会自动处理从 URL 中获取记录 ID 并查询数据的逻辑。
-->
<apex:pageBlock title="Account Details">
<!-- pageBlock 是一个用于组织页面内容的核心容器 -->
<apex:pageBlockSection columns="2">
<!-- pageBlockSection 用于将字段分组，columns="2" 表示两列布局 -->
<apex:outputField value="{! Account.Name }" />
<!-- outputField 会根据字段类型自动渲染，并尊重 FLS 设置 -->
<apex:outputField value="{! Account.Phone }" />
<apex:outputField value="{! Account.Industry }" />
<apex:outputField value="{! Account.AnnualRevenue }" />
</apex:pageBlockSection>
</apex:pageBlock>
</apex:page>
示例 2: 使用自定义控制器显示记录列表
当我们需要实现超越标准控制器能力的逻辑时，例如显示一个相关记录的列表，就需要自定义控制器。
Visualforce Page (ContactList.vfp)
<!--
Visualforce Page: ContactList
Description: Displays a list of contacts using a custom Apex controller.
-->
<apex:page controller="ContactListController">
<!-- controller 属性指向我们的自定义 Apex 控制器类 -->
<apex:pageBlock title="Contact List">
<!-- apex:pageBlockTable 用于以表格形式显示一个记录集合 -->
<apex:pageBlockTable value="{! contacts }" var="contact">
<!--
value="{! contacts }" 绑定到控制器中的 getContacts 方法。
var="contact" 定义了在循环中代表单个记录的变量名。
-->
<apex:column value="{! contact.FirstName }"/>
<apex:column value="{! contact.LastName }"/>
<apex:column value="{! contact.Email }"/>
<apex:column value="{! contact.Phone }"/>
</apex:pageBlockTable>
</apex:pageBlock>
</apex:page>
Apex Controller (ContactListController.apxc)
// Custom Apex controller to provide a list of contacts to a Visualforce page.
public with sharing class ContactListController {
// 属性，用于在 Visualforce 页面中通过 {!contacts} 访问
// getContacts 方法会在页面加载时被调用
public List<Contact> getContacts() {
// 使用 SOQL 查询返回前 10 个联系人记录
// 在生产环境中，查询应该更具选择性，并考虑排序和过滤
List<Contact> results = [SELECT Id, FirstName, LastName, Email, Phone FROM Contact LIMIT 10];
return results;
}
// with sharing 关键字确保该控制器在当前用户的共享权限下运行
// 这是安全架构的最佳实践
}
示例 3: 生成 PDF 文档
这个例子展示了 Visualforce 的杀手级功能：将页面内容渲染为 PDF。
<!--
Visualforce Page: InvoicePDF
Description: Generates a PDF invoice for an Opportunity.
-->
<apex:page standardController="Opportunity" renderAs="pdf">
<!--
renderAs="pdf" 是将页面渲染为 PDF 的关键属性。
applyBodyTag="false" 通常用于 PDF 渲染，以获得对样式的更精细控制。
-->
<head>
<style type="text/css" media="print">
@page {
/* CSS @page 指令用于控制 PDF 的页面边距、大小等 */
margin: 2cm;
}
body {
font-family: 'Arial Unicode MS';
}
</style>
</head>
<body>
<h1>Invoice for: {! Opportunity.Name }</h1>
<p><b>Account:</b> {! Opportunity.Account.Name }</p>
<p><b>Amount:</b>
<!-- apex:outputText 用于格式化输出，这里是货币格式 -->
<apex:outputText value="{0, number, 00.00}">
<apex:param value="{!Opportunity.Amount}" />
</apex:outputText>
</p>
<p><b>Close Date:</b>
<!-- 格式化日期输出 -->
<apex:outputText value="{0,date,MM/dd/yyyy}">
<apex:param value="{!Opportunity.CloseDate}" />
</apex:outputText>
</p>
</body>
</apex:page>
注意事项
作为架构师，在设计涉及 Visualforce 的解决方案时，必须充分考虑平台的限制和潜在风险。
1. 性能与 Governor Limits
- View State 限制: View State 的大小不能超过 170KB。这是最常见的性能瓶颈。要优化它，可以在 Apex 控制器中使用
transient关键字来标记不需要在请求之间保持状态的变量，从而将它们从 View State 中排除。同时，应避免在页面上加载不必要的数据。 - SOQL 查询限制: 每个事务中 SOQL 查询的总数不能超过 100 条，返回的总记录数不能超过 50,000 条。必须编写高效、批量化的 SOQL 查询，避免在循环中执行查询。
- 服务器端处理: Visualforce 的服务器端渲染模型意味着每次用户交互都可能涉及一次到服务器的往返。在网络延迟高的环境下，这会导致糟糕的用户体验。应谨慎使用需要频繁交互的功能。
2. 安全性
- 共享模型 (Sharing Model): 自定义控制器默认在系统模式（System Mode）下运行，会忽略用户的共享权限。必须在类定义中明确使用
with sharing关键字，以强制执行当前用户的共享规则。这是保证数据安全的核心要求。 - CRUD/FLS 权限: 同样，自定义控制器不会自动检查用户的对象和字段级权限。在 SOQL 查询中使用
WITH SECURITY_ENFORCED子句，或在 DML 操作前使用sObject.getSObjectType().getDescribe().isAccessible()等方法进行显式检查，是必不可少的安全措施。 - 跨站脚本 (XSS): Visualforce 默认会对
<apex:outputField>和表达式（{!...}）的输出进行 HTML 编码，以防止 XSS 攻击。但如果使用escape="false"属性，则必须确保输出的内容是安全可信的，否则会引入严重的安全漏洞。
3. 在 Lightning Experience 中的集成
- 外观不一致: 直接在 LEX 中嵌入未经优化的 Visualforce 页面会显得格格不入。使用
<apex:page lightningStylesheets="true">属性可以应用 Salesforce Lightning Design System (SLDS) 的样式，使其外观更接近原生 Lightning 组件，但这并非万能。 - 通信限制: Visualforce 页面与 LWC 之间的通信比 LWC 组件之间的通信要复杂。虽然可以通过 PostMessage API 或 Lightning Message Service (LMS) 实现，但这增加了架构的复杂性。
总结与最佳实践
Visualforce 就像一位经验丰富的老兵。虽然不再冲锋陷阵，但在特定战场上，它的经验和独特技能依然无可替代。作为 Salesforce 架构师，我们的职责是人尽其才，物尽其用。
架构设计最佳实践：
- LWC 优先原则: 对于所有新的 UI 开发项目，应默认选择 LWC。只有当遇到 LWC 无法原生满足的需求（如 PDF 生成、Visualforce 邮件模板）或维护现有应用时，才考虑使用 Visualforce。
- 职责分离: 即使在使用 Visualforce，也要保持良好的架构分层。将复杂的业务逻辑从控制器中抽离到可重用的 Apex 服务类中。这样，当未来需要将前端迁移到 LWC 时，核心的后端逻辑可以无缝复用。
- 性能至上: 严格监控和控制 View State 大小。对所有 SOQL 查询进行性能审查。对于数据量大的页面，考虑使用分页、懒加载或 JavaScript Remoting 等技术来提升用户体验。
- 安全第一: 永远不要忘记在自定义控制器中添加
with sharing。始终在代码中强制执行 CRUD/FLS 检查。将安全融入到设计的每一个环节。 - 明智地集成: 当需要在 LEX 中嵌入 Visualforce 页面时，投入时间去优化其外观和性能。使用
lightningStylesheets="true"并尽可能遵循 SLDS 的设计规范，确保用户体验的连贯性。
总而言之，Visualforce 并非过时的技术，而是一个成熟、稳定且在特定领域依然强大的工具。一个优秀的架构师不会盲目追逐潮流，而是能根据业务需求、成本效益和长期可维护性，为正确的问题选择正确的工具。在我们的 Salesforce 工具箱中，Visualforce 依然占有一席之地。
评论
发表评论