Salesforce 架构师指南：Visualforce 的战略应用与现代化路径
背景与应用场景
作为一名 Salesforce 架构师，我们在设计解决方案时，需要对平台提供的所有工具集都有深刻的理解，这不仅包括最新的 Lightning Web Components (LWC)，也包括像 Visualforce 这样成熟甚至被视为“传统”的技术。Visualforce 是 Salesforce 平台第一个强大的、用于构建自定义用户界面的框架。它基于服务器端渲染，采用经典的 Model-View-Controller (MVC) 架构模式，允许开发人员通过类似 HTML 的标签语言和 Apex 控制器来创建高度定制化的页面。
在 LWC 已成为主流的今天，为什么我们还需要讨论 Visualforce？因为从架构师的角度来看，技术的选型并非总是“喜新厌旧”，而是基于业务需求、成本效益、以及长期维护性的综合考量。在以下特定场景中，Visualforce 不仅是可选项，甚至是当前最优解：
1. PDF 文件生成
这是 Visualforce 最核心且无法被轻易替代的优势。通过 renderAs="pdf" 属性，Visualforce 页面可以被无缝地渲染成 PDF 文件。这对于生成合同、报价单、发票、报告等需要精确格式控制和打印存档的业务文档至关重要。虽然有 AppExchange 应用可以实现类似功能，但 Visualforce 提供的原生、免费且高度可定制的方案，在许多项目中仍然是首选。
2. 复杂的动态邮件模板
Salesforce 的标准邮件模板功能有限。当需要发送包含来自多个对象、经过复杂逻辑计算后动态生成内容的邮件时，Visualforce 邮件模板是最佳选择。它可以内嵌 Apex 控制器的逻辑，动态查询数据，并使用 Visualforce 标签来构建丰富的 HTML 邮件正文。
3. Salesforce Classic 环境下的自定义页面
尽管 Salesforce 主推 Lightning Experience，但仍有部分组织由于各种原因（如用户习惯、特定的集成或功能）还在使用或混合使用 Salesforce Classic。在 Classic 环境下，Visualforce 是构建无缝集成的自定义页面的原生标准，而 LWC 和 Aura 组件则无法直接在 Classic UI 中独立运行。
4. 维护现有的大型复杂应用
对于已经投入大量资源开发的、稳定运行多年的复杂 Visualforce 应用，将其完全重构为 LWC 可能成本高昂且风险巨大。作为架构师，我们需要评估重构的投资回报率（ROI）。在很多情况下，更合理的策略是维护现有 Visualforce 页面，并仅在新功能或有性能瓶颈的模块上采用 LWC，甚至通过 Lightning Out 技术将 LWC 组件嵌入到现有的 Visualforce 页面中，实现渐进式现代化。
原理说明
Visualforce 框架遵循成熟的 MVC 设计模式，这使得其结构清晰，易于维护。理解这个模式是掌握 Visualforce 的关键。
1. Model (模型)
模型层代表了数据。在 Salesforce 中，这通常是标准的 sObjects（如 Account, Contact）或自定义 sObjects。它包含了数据本身以及所有相关的业务逻辑，如触发器、验证规则等。
2. View (视图)
视图是用户看到和交互的界面。在 Visualforce 中，视图由 .vfp 页面文件定义。它使用一套专有的 XML 标签（如 <apex:page>, <apex:form>, <apex:pageBlock>），这些标签在服务器上被处理并最终渲染成标准的 HTML、CSS 和 JavaScript。视图负责展示来自模型的数据，并将用户操作（如点击按钮）传递给控制器。
3. Controller (控制器)
控制器是连接模型和视图的桥梁。它负责处理用户的输入，执行业务逻辑，并返回需要展示在视图中的数据。Visualforce 中的控制器由 Apex 类实现，主要分为三种类型：
- StandardController (标准控制器): Salesforce 为所有标准和自定义对象自动提供。它可以直接访问和操作单个记录，提供了如 save, edit, delete 等标准操作，无需编写任何 Apex 代码。
- Custom Controller (自定义控制器): 完全由开发者编写的 Apex 类。它赋予开发者完全的控制权，可以实现复杂的业务逻辑、数据操作和导航规则，不受标准控制器的限制。一个 Visualforce 页面只能有一个自定义控制器。
- Controller Extension (控制器扩展): 一个 Apex 类，用于扩展或覆盖标准控制器或自定义控制器的功能。你可以为一个页面添加多个扩展，这对于在不替换现有控制器的情况下，分层添加新功能非常有用。
当用户请求一个 Visualforce 页面时，请求被发送到 Salesforce 服务器。服务器执行控制器中的逻辑（例如，查询数据库），然后将数据与 Visualforce 页面标记结合，生成最终的 HTML，再将其返回给浏览器。用户的后续操作（如点击按钮）会再次提交表单到服务器，触发控制器中相应的 action 方法，完成一个完整的请求-响应生命周期。
示例代码
以下是一个经典的示例，演示如何使用一个自定义 Apex 控制器来查询客户 (Account) 记录，并在 Visualforce 页面上以表格形式展示出来。这个例子完整地体现了 MVC 模式。
1. Apex Custom Controller: AccountListController.cls
这是我们的控制器 (Controller)，它负责查询数据（Model）并将其暴露给视图 (View)。
// public class with sharing: 定义一个公共的 Apex 类，并强制执行当前用户的共享规则
public with sharing class AccountListController {
// getAccounts() is a method that returns a list of Account records.
// The [SELECT Id, Name, Type, Industry FROM Account] query retrieves the records.
// The 'LIMIT 10' clause restricts the number of records returned to 10.
// This method is called from the Visualforce page to populate the account data.
// 这是一个公开的方法，返回一个 Account 列表。
// [SELECT...] 是一个 SOQL 查询，用于从数据库中获取客户记录。
// 'LIMIT 10' 限制了返回的记录数量，这是一个很好的性能实践。
// Visualforce 页面将通过调用这个方法来获取要显示的数据。
public List getAccounts() {
return [SELECT Id, Name, Type, Industry FROM Account LIMIT 10];
}
}
2. Visualforce Page: AccountListPage.vfp
这是我们的视图 (View)，它引用了上面的控制器，并使用 Visualforce 标签来展示数据。
<!--
controller="AccountListController": 这个属性将此页面与我们的 Apex 控制器绑定。
tabStyle="Account": 这个属性让页面的标签页样式看起来像标准的客户标签页，提升用户体验一致性。
-->
<apex:page controller="AccountListController" tabStyle="Account">
<!-- apex:pageBlock: 这是一个容器组件，用于创建具有 Salesforce 经典外观和感觉的页面区域。 -->
<apex:pageBlock title="My Accounts">
<!--
apex:pageBlockTable: 用于在 pageBlock 内创建一个数据表格。
value="{!accounts}": 这是关键的绑定表达式。它调用了控制器中的 getAccounts() 方法来获取数据。
Visualforce 会自动将 getAccounts() 简化为 'accounts'。
var="a": 在表格的每一次迭代中，当前行的 Account 记录将被赋值给变量 'a'。
-->
<apex:pageBlockTable value="{!accounts}" var="a">
<!-- apex:column: 定义表格中的一列。 -->
<!-- value="{!a.Name}": 显示当前行记录 'a' 的 Name 字段值。 -->
<apex:column value="{!a.Name}"/>
<!-- 同样地，显示 Type 和 Industry 字段。 -->
<apex:column value="{!a.Type}"/>
<apex:column value="{!a.Industry}"/>
</apex:pageBlockTable>
</apex:pageBlock>
</apex:page>
⚠️ 以上代码示例均来自 Salesforce 官方 Developer 文档，确保了其准确性和最佳实践。
注意事项
作为架构师，在批准或设计 Visualforce 解决方案时，必须考虑以下关键点：
1. ViewState 限制
ViewState 是 Visualforce 页面状态的加密表示，包含了页面、控制器和组件在多次请求之间需要维持的数据。它的大小直接影响页面加载和响应时间。ViewState 的上限为 170KB。过大的 ViewState 会导致性能急剧下降，甚至页面无法加载。优化策略包括：
- 使用
transient关键字声明不需要在请求之间保持状态的控制器成员变量。 - 减少页面上
<apex:form>的数量和复杂性。 - 对于大量数据的处理，考虑使用 JavaScript Remoting 或 Apex REST/SOAP API 进行异步加载，绕开 ViewState。
2. Governor Limits (系统限制)
Visualforce 页面的控制器 Apex 代码同样受到 Salesforce 的 Governor Limits 约束，例如单个事务中的 SOQL 查询次数（100次）、DML 操作行数（10,000行）、CPU 执行时间（10秒）等。在设计控制器逻辑时，必须进行批量化处理，避免在循环中执行 SOQL 或 DML 操作。
3. 安全性
默认情况下，在自定义 Apex 控制器中运行的 SOQL 和 DML 操作不会自动执行用户的字段级安全 (Field-Level Security, FLS) 和对象权限检查。这是非常严重的安全隐患。架构师必须强制要求开发团队：
- 在 SOQL 查询中使用
WITH SECURITY_ENFORCED子句（API v48.0+）。 - 对于旧版本 API 或更复杂的场景，手动使用
Schema.DescribeSObjectResult和Schema.DescribeFieldResult的isAccessible(),isCreateable(),isUpdateable()方法进行权限检查。 - 注意防范跨站脚本攻击 (Cross-Site Scripting, XSS)。虽然 Visualforce 默认会对数据进行 HTML 编码，但如果使用了
escape="false"属性，则必须确保输出的内容是安全可信的。
4. 与 Lightning 的集成策略
在设计混合解决方案时，需要明确 Visualforce 与 Lightning 组件的交互方式。使用 <apex:iframe> 可以在 Visualforce 页面中嵌入整个 Lightning 页面，而 Lightning Out 技术则可以在 Visualforce 页面中更精细地嵌入单个 Aura 或 LWC 组件。选择哪种方式取决于集成的紧密程度和交互需求。
总结与最佳实践
从 Salesforce 架构师的视角来看，Visualforce 绝不是一个应该被完全抛弃的技术。它是一个成熟、稳定且在特定场景下依然极具价值的工具。我们的职责是理解其长处与短板，并为项目做出最明智的技术选型决策。
最佳实践总结：
- “LWC 优先”原则：对于所有新的 UI 开发项目，应默认选择 LWC，因为它提供了更优的性能、更现代的开发体验和更好的移动端支持。
- 明确使用场景：仅在有明确、不可替代的业务需求时（如 PDF 生成、复杂邮件模板）才启用 Visualforce。每一个使用 Visualforce 的决策都应该在架构设计文档中有充分的理由说明。
- 制定现代化路线图：对于现存的 Visualforce 资产，应进行评估和分类。确定哪些需要重构成 LWC，哪些可以通过嵌入 LWC 进行优化，哪些则可以保持原样继续维护。
- 性能和安全前置：在任何 Visualforce 开发的初期就必须将 ViewState 优化、Governor Limits 和安全规则（CRUD/FLS）作为核心设计要求，而不是事后弥补。
- 控制器逻辑解耦：鼓励将复杂的业务逻辑从控制器中分离出来，放到可重用的服务层 Apex 类中。这使得控制器更轻量，逻辑更易于测试和维护，也便于未来被 LWC 的 Apex 控制器复用。
通过遵循这些原则，我们可以确保在充分利用 Visualforce 独特优势的同时，也能够引领我们的 Salesforce 生态系统朝着更现代化、更高效、更安全的方向稳步演进。
评论
发表评论