Module 13: Strategies for Designing Efficient Apex Solutions

1

第 329 页

今天我们来聊聊Salesforce中的Apex Solutions，特别是如何高效设计策略。Apex是Salesforce的一种编程语言，它允许我们创建复杂的业务逻辑和自定义功能。但是，要想高效地使用Apex，我们需要一些设计策略。首先，我们要明白，Apex代码是在Salesforce的多租户环境中运行的，这意味着我们的代码需要高效，不能占用太多资源。所以，我们在设计Apex解决方案时，要考虑到性能优化。一个重要的策略是尽量减少数据库操作。每次我们访问数据库，都会消耗资源。所以，我们应该尽量在一次操作中获取所有需要的数据，而不是多次访问数据库。这可以通过使用SOQL查询的批量处理来实现。其次，我们要避免在循环中进行数据库操作。这会导致所谓的“SOQL查询在循环中”问题，它会显著降低性能。我们应该在循环外部获取数据，然后在循环内部处理这些数据。另外，我们还要注意Apex的触发器设计。触发器是在数据库操作（如插入、更新、删除）前后自动执行的代码。为了保持触发器的效率，我们应该遵循“一个对象一个触发器”的最佳实践，这样可以避免触发器之间的冲突和性能问题。最后，我们要确保我们的Apex代码是可维护的。这意味着我们要编写清晰的、有良好注释的代码，并且遵循Salesforce的最佳实践和编码标准。这样，不仅我们自己以后可以更容易地理解和修改代码，其他开发人员也能更容易地接手和维护。总之，高效设计Apex解决方案的关键在于性能优化、避免不必要的数据库操作、合理设计触发器，以及编写可维护的代码。记住这些策略，你就能在Salesforce平台上创建出既强大又高效的Apex解决方案了。

查看详情

2

Apex Best Practices

第 330 页

让我们来聊聊Apex最佳实践，特别是如何编写易于维护和扩展的代码，以及如何避免常见的性能问题。首先，编写易于维护和扩展的代码是非常重要的。这意味着你的代码应该清晰、简洁，并且有良好的注释。你可以通过使用有意义的变量名和方法名来做到这一点。此外，尽量遵循单一职责原则，即每个类或方法只做一件事。这样，当需求变化时，你可以更容易地修改或扩展代码，而不影响其他部分。接下来，假设批量数据作为输入来编写触发器和类。这意味着你的代码应该能够处理大量数据，而不仅仅是单条记录。例如，在触发器中，你应该使用`Trigger.new`或`Trigger.old`来处理一组记录，而不是逐条处理。这样可以避免在大量数据时触发器的性能问题。在查询和使用TLR（Transaction Log Records）时，与数据库高效配合使用代码也非常关键。你应该尽量减少数据库查询的次数，尽量在一次查询中获取所有需要的数据。使用`SOQL`查询时，尽量避免在循环中执行查询，这样可以减少数据库的负载，提高性能。现在，关于你提到的遗留触发器失败和限制问题，我们可以从以下几个方面来修复： 1. ，优化查询，：检查触发器中的查询，确保它们是最优的。避免在循环中执行查询，尽量使用集合和映射来减少查询次数。 2. ，批量处理，：确保触发器能够处理批量数据。使用`Trigger.new`来处理一组记录，而不是逐条处理。 3. ，测试案例，：确保你的测试案例覆盖了各种场景，包括批量数据和边界情况。这样可以帮助你发现潜在的问题。 4. ，监控限制，：使用`System.debug`或`Limits`类来监控代码中的限制使用情况。这样可以帮助你识别哪些部分代码消耗了过多的资源。 5. ，代码重构，：如果可能，重构遗留代码，使其更符合最佳实践。这可能包括拆分大型触发器为多个小型触发器，或者将业务逻辑移到辅助类中。通过这些步骤，你可以逐步修复遗留触发器的问题，并确保你的代码更高效、更易于维护。希望这些建议对你有所帮助！

查看详情

3

Module Agenda - 331

第 331 页

同学们，今天我们来聊聊Salesforce中的Apex编程，特别是如何设计高效的Apex解决方案。这个模块的内容非常实用，可以帮助你们在Salesforce开发中更加得心应手。首先，我们要讲的是，高效使用数据库，。在Salesforce中，数据库操作是非常频繁的，所以如何高效地使用数据库就显得尤为重要。我们要学会使用SOQL和SOSL查询语言，尽量减少查询次数，避免在循环中进行查询，这样可以大大减少数据库的负载。接下来是，设计触发器，。触发器是Salesforce中非常强大的工具，可以在记录插入、更新或删除时自动执行一些操作。但是，触发器如果设计不当，可能会导致性能问题。所以，我们要确保触发器中的逻辑简洁高效，避免在触发器中执行复杂的操作，尽量把复杂的逻辑放到Apex类中处理。最后，我们要讲的是，设计课程，。这里的“课程”其实是指如何系统地学习和掌握Apex编程。我们要从基础开始，逐步深入，理解Apex的核心概念，比如类、对象、方法等。然后通过实际的项目来巩固这些知识，这样才能真正掌握Apex编程。总结一下，今天的内容主要是围绕如何设计高效的Apex解决方案展开的。我们讨论了高效使用数据库、设计触发器以及如何系统地学习Apex编程。希望这些内容对你们有所帮助，能够在实际开发中派上用场。好了，今天的课程就到这里，大家有什么问题可以随时提问。谢谢！

查看详情

4

Key Query Limits

第 332 页

同学们，今天我们来聊聊Salesforce中的SOQL查询限制，特别是关于堆大小和事务内存使用的问题。首先，SOQL是Salesforce Object Query Language的缩写，它是用来从Salesforce数据库中检索数据的。但是，Salesforce对SOQL查询有一些限制，主要是为了防止资源过度使用，保证系统的稳定性和性能。，堆大小限制，：每次事务执行时，Salesforce都会分配一定量的内存，这就是所谓的堆大小。如果SOQL查询返回的数据量太大，或者你在一个事务中执行了太多的查询，就可能会超出这个堆大小的限制，导致错误。，事务内存使用，：每个事务在执行时，都会消耗一定的内存。如果你在一个事务中执行了多个SOQL查询，或者查询返回了大量的数据，这都会增加内存的使用量。如果超出了Salesforce设定的限制，事务就会失败。，讨论这些限制的含义，：这些限制意味着我们在编写代码时，必须非常小心。我们需要确保我们的SOQL查询是高效的，避免不必要的数据检索，特别是在循环中执行SOQL查询，这会导致每次循环都执行一次查询，极大地增加了内存的使用。，下一张幻灯片将回顾不良代码和解决方案，：接下来，我们会看一些常见的错误代码示例，以及如何优化这些代码来避免超出Salesforce的限制。我们会学习如何重构代码，比如将SOQL查询移出循环，或者使用批量处理来减少查询次数。记住，理解并遵守这些限制，不仅能帮助我们避免错误，还能提高我们应用的整体性能和用户体验。希望大家在编写代码时，都能时刻注意这些要点。

查看详情

5

Anti-Pattern: Querying within a Loop

第 333 页

同学们，今天我们来聊聊一个在Salesforce开发中非常常见但需要特别注意的问题——在循环内进行查询。这个做法被称为“反模式”，也就是说，它是一种不太好的编程习惯，可能会导致你的代码出现问题。首先，让我们看看这段代码。这段代码的目的是在循环中查询每个课程参与者的信息，并收集他们的电子邮件地址。看起来好像没什么问题，对吧？但实际上，这里有一个很大的隐患。问题出在循环内的查询。每次循环执行时，都会触发一次数据库查询。想象一下，如果你有100个课程参与者，那么这段代码就会执行100次查询！这听起来可能不多，但在Salesforce中，每次查询都会消耗一定的资源。Salesforce对每次执行的代码都有严格的资源限制，称为“Apex调控器限制”。这些限制包括查询次数、查询返回的行数、执行时间等。如果你在循环内进行查询，很容易就会超出这些限制。比如，Salesforce规定每次执行最多只能进行100次查询。如果你的循环次数超过100次，代码就会因为超出查询限制而失败。这不仅会导致功能无法正常工作，还可能影响整个系统的性能。所以，正确的做法是尽量避免在循环内进行查询。你可以考虑在循环外部一次性查询所有需要的数据，然后在循环中处理这些数据。这样，你只需要执行一次查询，大大减少了资源消耗，也避免了超出调控器限制的风险。总结一下，记住这个关键点：在Salesforce开发中，尽量避免在循环内进行查询。这不仅能让你的代码更高效，还能避免很多潜在的问题。希望这个讲解对你们有帮助，下次写代码时一定要注意哦！

查看详情

6

Principle: Use Collections to Minimize the Number of Queries

第 334 页

同学们，今天我们来聊聊一个在Salesforce开发中非常重要的原则——使用集合来最大限度地减少查询数量。这个原则听起来可能有点复杂，但其实很简单，我们一步步来理解。首先，想象一下，如果你每次需要数据时都去数据库里查询一次，那会非常耗时，对吧？特别是在循环中，如果每次循环都去查询一次，那效率就会非常低。这就是我们说的“循环中查询的反模式”。那么，我们怎么解决这个问题呢？步骤#1就是排除SOQL查询。SOQL是Salesforce的查询语言，用来从数据库中获取数据。我们需要构造一个标准，看看有多少个SOQL查询是可以避免的。这里的关键是使用集合。集合是什么呢？简单来说，集合就是一组数据的容器。我们可以先把需要的数据一次性查询出来，放到集合里，然后在循环中使用这个集合，而不是每次都去查询数据库。举个例子，假设我们有一组客户记录，我们需要对每个客户进行一些操作。如果我们每次循环都去查询一次客户记录，那就会非常慢。但如果我们先把所有客户记录查询出来，放到一个集合里，然后在循环中使用这个集合，那就会快很多。所以，同学们，记住这个原则：使用集合来最大限度地减少查询数量。这样不仅能提高代码的效率，还能减少对数据库的压力。希望这个解释对你们有帮助！

查看详情

7

Be Aware: Parent-Child Queries are Counted Differently

第 335 页

今天我们来聊聊Salesforce中的SOQL查询和它们的限额计数，特别是当涉及到父子关系的时候。首先，SOQL是Salesforce Object Query Language的缩写，它是用来从Salesforce数据库中检索数据的。在Salesforce中，每次执行SOQL查询都会消耗一定的限额。这个限额是有限制的，所以我们需要非常注意如何编写我们的查询，以确保我们不会超出这个限额。现在，让我们来看看两个关键点： 1. ，主SOQL查询，：每次执行一个主SOQL查询，它会计为100个查询限额中的1个。这意味着如果你执行了100个这样的查询，你就达到了你的限额。 2. ，嵌套SOQL查询，：当你有一个嵌套的SOQL查询，也就是在查询中包含子查询时，情况就有点不同了。每个嵌套的SOQL查询会计为300个查询限额中的1个。这是因为嵌套查询通常涉及更复杂的操作，比如处理父子关系，所以Salesforce给它们更高的限额。这里有一个教学要点：包含子查询的查询可能会影响你的限额计数。这意味着如果你在查询中使用了子查询，特别是涉及到父子关系的子查询，你需要更加小心，因为这些查询会更快地消耗你的限额。为了帮助你更好地理解这一点，我建议你查看Salesforce的官方文档和社区论坛。这些资源提供了关于SOQL查询限额的详细信息，包括如何处理父子关系查询以及如何优化你的查询以避免超出限额。记住，合理使用SOQL查询，不仅可以提高你的应用性能，还可以避免不必要的限额消耗。希望这些信息对你有所帮助，如果你有任何问题，随时提问！

查看详情

8

Principle: Bring Back What You Need in a Single Query

第 336 页

同学们，今天我们来聊聊Salesforce中的一个重要原则——在一次查询中带回你需要的内容。这个原则听起来简单，但实际操作中却非常关键。想象一下，你去超市买东西。如果你每次只买一样东西，然后回家，再去买另一样，这样来回跑不仅浪费时间，还消耗精力。同样地，在Salesforce中，如果你每次只查询一小部分数据，然后再去查询更多，这样不仅效率低下，还可能影响系统的性能。所以，我们的目标是：在一次查询中，尽可能多地收集你需要的所有数据。这就是我们说的“不要再回去拿更多了”。具体怎么做呢？首先，你需要明确你需要哪些数据。然后，在你的SOQL查询中，直接从相关的sObject中引入这些字段。这样，你就能在一次查询中获取所有必要的信息，而不需要多次往返数据库。举个例子，如果你需要客户的姓名、地址和最近的订单信息，你应该在一个查询中同时获取这些数据，而不是分别查询姓名、地址和订单。记住，优化你的查询不仅能提高效率，还能让你的应用运行得更顺畅。所以，下次写查询时，记得这个原则：一次查询，带回所有你需要的内容。好了，这就是今天的内容。希望你们能理解并应用这个原则，让你们的Salesforce开发更加高效。如果有任何问题，随时提问！

查看详情

9

Principle: Reducing the Data Set

第 337 页

同学们，今天我们来聊聊如何在Salesforce中优化我们的触发器（Trigger），特别是如何通过减少数据集来提高效率。想象一下，你有一个大箱子，里面装满了各种颜色的球，但你只需要红色的球。如果你把整个箱子都倒出来找红色的球，那会非常耗时。所以，我们得想办法只拿出红色的球，这样效率就高多了。在我们的Salesforce触发器里，情况也类似。假设我们有一个触发器，它会在每次有200条记录被更新时触发。但是，我们真正关心的可能只有其中的20条记录。如果我们不加以筛选，直接处理这200条记录，那就会浪费很多资源。那么，我们怎么做到只处理我们关心的那20条记录呢？这里就需要用到过滤器了。我们可以设置一个条件，比如只处理那些状态没有改变的记录。在Salesforce中，我们可以使用`Trigger.oldMap`来获取更新前的记录状态，然后与更新后的状态进行比较。如果状态没有改变，我们就可以跳过这些记录，不对它们进行SOQL查询，这样就大大减少了不必要的数据处理。总结一下，我们的目标是通过添加过滤器，只带回我们需要的数据，就像只从箱子里拿出红色的球一样。这样做不仅能提高触发器的执行效率，还能减少系统的负担。希望这个比喻能帮助大家更好地理解这个概念。如果有任何疑问，随时提问哦！

查看详情

10

Principle: Use SOQL For Loops to Reduce Heap Size

第 338 页

今天我们来聊聊SOQL For Loops，这是一个非常实用的工具，可以帮助我们更有效地处理Salesforce中的数据。首先，SOQL For Loops是一种特殊的循环方式，它允许我们分批处理从SOQL查询中返回的大量记录。这样做的好处是可以减少内存的使用，也就是我们常说的“堆大小”。在Salesforce中，堆大小是有限的，所以我们需要尽可能地优化我们的代码，以避免超出这个限制。使用SOQL For Loops时，Salesforce会自动将查询结果分成较小的批次，通常是200条记录一批。这样，我们就可以在每次循环中只处理一小部分数据，而不是一次性加载所有数据到内存中。这种方法特别适合处理大量数据，因为它可以显著减少内存的消耗。举个例子，假设我们有一个查询返回了1000条记录。如果我们不使用SOQL For Loops，而是直接将这1000条记录加载到内存中，那么堆大小会迅速增加。但是，如果我们使用SOQL For Loops，Salesforce会将这些记录分成5个批次，每批200条。这样，每次循环我们只需要处理200条记录，大大减少了内存的使用。总结一下，SOQL For Loops是处理大量数据时的好帮手。它通过分批处理数据，帮助我们有效地管理堆大小，避免内存溢出的问题。希望这个简单的解释能帮助你更好地理解和使用SOQL For Loops。

查看详情

11

Tip for Improving SOQL Performance

第 339 页

今天我们来聊聊如何提高SOQL查询的性能。虽然我们不会深入探讨所有细节，但有几个关键点可以帮助你优化查询。首先，，滤波器，的使用非常重要。在SOQL查询中，尽量使用那些已经被索引的字段作为过滤条件。索引字段就像是书的目录，能快速帮你找到需要的信息，而不是一页一页地翻。比如，使用`CreatedDate`或`Id`这样的字段，通常比使用非索引的字符串或整数字段要快得多。其次，，外部Id，也是一个很好的选择。如果你在查询中使用了外部Id字段，Salesforce会自动为这些字段创建索引，这样查询速度会更快。外部Id通常用于集成场景，比如从外部系统导入数据时使用。最后，如果你想了解更多关于哪些字段是默认被索引的，可以参考Salesforce的官方文档。文档中列出了哪些字段类型会自动被索引，比如`CreatedDate`、`LastModifiedDate`、`Id`等。总结一下，优化SOQL查询的关键在于选择合适的过滤条件，尽量使用索引字段或外部Id，这样可以大大提高查询效率。希望这些小技巧对你有帮助！

查看详情

12

13-1: Refactor a Trigger to Avoid SOQL Limits

第 340 页

同学们，今天我们来聊聊如何重构Salesforce中的触发器，以避免SOQL查询限制的问题。首先，我们需要理解什么是SOQL查询限制。在Salesforce中，每个事务（比如保存一条记录）最多只能执行100次SOQL查询。如果超过了这个限制，系统就会抛出“SOQL查询太多”的错误。现在，假设我们有一个触发器，它会在课程记录被插入或更新时执行一些操作。这个触发器可能会在每次记录操作时执行一个SOQL查询，来获取相关的数据。如果我们一次性插入或更新多条记录，这个触发器就会为每条记录执行一次SOQL查询，这样很容易就会超过100次的限制。为了避免这种情况，我们需要重构我们的触发器。重构的关键在于减少SOQL查询的次数。我们可以通过以下几种方式来实现： 1. ，批量处理，：确保触发器能够处理一组记录，而不是单个记录。这样，我们就可以在触发器外部收集所有需要的数据，然后一次性执行SOQL查询。 2. ，使用集合，：在触发器中，使用集合（如Set或Map）来存储和处理数据，这样可以减少重复的SOQL查询。 3. ，优化查询，：尽量编写高效的SOQL查询，避免不必要的字段和条件，减少查询的复杂度。 4. ，使用静态变量，：如果某些数据在事务中是静态的，可以使用静态变量来存储这些数据，避免重复查询。接下来，我们可以在Salesforce用户界面中测试这个触发器，确保它在处理单个记录时工作正常。然后，我们需要编写单元测试代码，用多个记录来测试触发器，确保它在批量操作时也不会超过SOQL查询限制。最后，根据测试结果，我们可能需要进一步调整和优化触发器的代码，确保它在各种情况下都能高效运行，不会触发SOQL查询限制。这就是我们今天的内容，希望大家能够理解并掌握如何重构触发器以避免SOQL查询限制。如果有任何问题，欢迎随时提问。

查看详情

13

Key DML Limits

第 341 页

同学们，今天我们来聊聊Salesforce中的一些关键限制，特别是关于TLR（Transaction Log Replay）的限制。这些限制对于确保系统的稳定性和性能非常重要。首先，我们来看第一个限制：，已发布的TLR声明总数，。这个限制指的是在Salesforce中，你可以发布的TLR声明的最大数量。TLR声明是用来记录事务的，所以这个限制实际上是在控制你可以记录多少事务。如果超过了这个限制，系统可能会拒绝新的TLR声明，导致一些事务无法被记录。接下来是第二个限制：，由于TLR声明而处理的记录总数，。这个限制关注的是由于TLR声明而被处理的记录数量。也就是说，每次TLR声明可能会涉及到多个记录的更新或创建。这个限制是为了防止单个TLR声明处理过多的记录，从而避免系统资源的过度消耗。最后，我们来看第三个限制：，总堆大小，。堆大小是指Salesforce在执行事务时使用的内存大小。这个限制是为了防止单个事务占用过多的内存，从而影响其他事务的执行。如果堆大小超过了限制，系统可能会抛出异常，导致事务失败。总结一下，这三个限制都是为了保护Salesforce系统的稳定性和性能。它们分别控制了TLR声明的数量、每个TLR声明处理的记录数量以及事务使用的内存大小。理解这些限制有助于我们在开发和管理Salesforce应用时，避免超出系统的承载能力。下一张幻灯片，我们将进一步检查这些限制的具体数值和如何在实际应用中应对这些限制。希望大家能跟上节奏，有任何问题随时提问！

查看详情

14

Anti-Pattern: DML statements

第 342 页

让我们来聊聊Salesforce中的反模式，特别是关于TLR（Trigger Logic Reuse）声明的问题。首先，什么是TLR声明呢？简单来说，TLR声明是一种在触发器中使用的方法，目的是为了重用逻辑代码。听起来不错，对吧？但是，如果在循环中进行ADL（Apex Data Loader）操作，你的代码可能会遇到一些严重的问题。想象一下，你有一个触发器，它在每次记录更新时都会执行一些逻辑。如果你在循环中对每个记录都执行TLR声明，那么每次循环都会触发一次完整的逻辑执行。这不仅效率低下，而且你的代码可能会很快达到Apex管理器的限制。 Apex管理器有一些严格的限制，比如每个事务中最多只能执行100个SOQL查询，或者最多只能执行10,000条DML语句。如果你的代码在循环中频繁执行TLR声明，很容易就会超过这些限制，导致代码失败。所以，为了避免这种情况，我们应该尽量避免在循环中进行TLR声明。相反，可以考虑在循环外部执行一次TLR声明，然后在循环内部只处理必要的逻辑。这样不仅可以提高代码的效率，还能避免达到Apex管理器的限制。总结一下，TLR声明虽然有用，但在循环中使用时要特别小心。记住，好的代码不仅要功能正确，还要高效且符合平台的最佳实践。希望这个解释对你有帮助！

查看详情

15

Principle: Batch Data for DML Statements

第 343 页

让我们来聊聊TLR陈述的批数据处理要点。首先，我们要明白，处理大量数据时，效率是关键。这里，我们使用集合（Set）来帮助我们提高效率。，步骤#1：排除因素，在处理TLR（假设这是一个特定的数据记录类型）时，我们首先需要排除那些不需要处理的记录。这就像你在整理收件箱时，先过滤掉那些垃圾邮件一样。通过排除这些因素，我们可以减少需要处理的数据量，从而提高效率。，集合的使用，集合在这里起到了非常重要的作用。集合是一种数据结构，它不允许有重复的元素。这意味着，当我们把TLR记录放入一个集合中时，任何重复的记录都会被自动排除。这样，我们就避免了多次处理相同的TLR陈述，从而节省了时间和资源。，教学要点，使用集合不仅简化了数据处理流程，还显著提高了效率。特别是在处理像收件箱记录这样的数据时，集合帮助我们避免了重复处理，确保每一条记录只被处理一次。这种方法不仅节省了时间，还减少了出错的可能性。总结一下，通过使用集合来排除重复的TLR陈述，我们可以更高效地处理批数据，确保每一条记录都得到适当的处理，而不会浪费资源在重复的任务上。希望这个解释能帮助你更好地理解TLR批数据处理的要点！

查看详情

16

Principle: Use SOQL For Loops to Make Batches of 200

第 344 页

让我们来聊聊如何在Salesforce中使用SOQL For Loops来批量处理数据，特别是当我们需要创建大量记录时，比如200条记录。这个方法不仅高效，还能帮助我们减少堆大小，避免系统资源的过度消耗。首先，SOQL For Loops是什么？简单来说，它是一种在Apex中处理大量数据的有效方式。当你执行一个SOQL查询时，如果返回的结果集非常大，直接处理可能会导致堆大小超出限制。SOQL For Loops通过分批处理数据来解决这个问题。现在，假设我们需要创建200条记录。如果我们一次性处理所有数据，可能会遇到性能问题。但是，如果我们使用SOQL For Loops，就可以将这些记录分成更小的批次来处理，比如每次处理20条记录。这样做的好处是，每次只处理一小部分数据，堆大小就会保持在较低水平，从而避免系统资源的过度消耗。具体来说，你可以这样写代码： ```apex for (List records : [SELECT Id, Name FROM YourObject__c LIMIT 200]) { // 在这里处理每一批记录 // 比如，创建新的记录 List newRecords = new List(); for (YourObject__c record : records) { YourObject__c newRecord = new YourObject__c(); newRecord.Name = record.Name + ' - Copy'; newRecords.add(newRecord); } insert newRecords; } ``` 在这个例子中，我们首先查询了最多200条记录，然后使用SOQL For Loops来分批处理这些记录。每次循环中，我们只处理一小部分记录，这样就有效地减少了堆大小。总结一下，SOQL For Loops是一个非常强大的工具，特别是在处理大量数据时。它不仅能帮助我们高效地处理数据，还能避免系统资源的过度消耗。所以，下次当你需要处理大量数据时，记得使用SOQL For Loops，让你的代码更加高效和可靠。

查看详情

17

13-2: Refactor a Trigger to Avoid DML Limits

第 345 页

同学们，今天我们来聊聊如何重构Salesforce中的触发器，以避免“TLR行太多”的错误。这个错误通常发生在触发器处理大量记录时，超出了Salesforce对触发器执行行数的限制。我们的目标是让触发器更高效，同时确保它在处理多个记录时依然能够正常工作。首先，我们需要检查当前的课程触发器。打开你的开发环境，找到那个触发器，看看它的代码结构。通常，触发器会包含一些逻辑来处理插入、更新或删除操作。我们需要确保这些逻辑是简洁且高效的。接下来，我们要重构代码。重构的目的是减少触发器中的行数，同时保持其功能不变。我们可以通过以下几种方式来实现： 1. ，将逻辑移到Apex类中，：触发器中的复杂逻辑可以移到Apex类中。这样不仅减少了触发器的行数，还使得代码更易于维护和测试。 2. ，使用批量处理，：确保触发器能够处理批量记录，而不是逐条处理。这样可以减少触发器的执行次数，从而避免TLR错误。 3. ，优化查询和DML操作，：尽量减少在触发器中的查询和DML操作次数。可以通过合并查询或使用集合来优化这些操作。重构完成后，我们需要进行单元测试。编写测试代码时，确保使用多个记录来测试触发器。这样可以模拟真实场景，确保触发器在处理大量数据时不会出错。最后，运行你的测试代码，检查触发器是否能够正确处理多个记录，并且没有出现“TLR行太多”的错误。如果一切正常，恭喜你，你已经成功重构了触发器！记住，重构是一个持续的过程。随着业务需求的变化，你可能需要不断地优化和调整你的代码。保持代码的简洁和高效，是每个开发者的责任。好了，今天的课程就到这里。希望你们能够掌握如何重构触发器以避免TLR限制。如果有任何问题，随时提问。下次见！

查看详情

18

Module Agenda - 346

第 346 页

同学们，今天我们来聊聊如何在Salesforce中设计高效的Apex解决方案。这个模块的内容非常实用，尤其是当你需要处理大量数据时，掌握这些策略会让你的工作事半功倍。 ### 1. 高效使用数据库首先，我们要学会如何高效地使用数据库。在Salesforce中，数据库操作是非常常见的，但如果不注意，很容易导致性能问题。这里有几个小技巧： - ，批量处理，：尽量使用批量处理，而不是逐条处理数据。这样可以减少数据库的调用次数，提高效率。 - ，选择性查询，：在查询时，尽量只选择你需要的字段，避免使用`SELECT *`。这样可以减少数据传输量，提高查询速度。 - ，索引优化，：确保你的查询条件使用了索引字段，这样可以加快查询速度。 ### 2. 设计触发器接下来，我们来看看如何设计触发器。触发器是Apex中非常强大的工具，但如果不小心使用，可能会导致性能问题。这里有几个设计触发器的要点： - ，避免递归触发，：确保触发器不会无限递归调用自己。可以通过使用静态变量来控制触发器的执行次数。 - ，批量处理，：触发器应该能够处理批量数据，而不是只处理单条记录。这样可以提高触发器的效率。 - ，逻辑分离，：尽量将复杂的逻辑放在Apex类中，而不是直接写在触发器里。这样可以提高代码的可维护性和可测试性。 ### 3. 设计课程最后，我们来谈谈如何设计课程。这里的“课程”指的是你在Salesforce中设计的业务流程或逻辑。设计课程时，要注意以下几点： - ，模块化设计，：将复杂的业务流程分解成多个小模块，每个模块负责一个特定的功能。这样可以提高代码的可读性和可维护性。 - ，重用性，：尽量设计可重用的代码，避免重复造轮子。可以通过创建通用的Apex类或方法来实现。 - ，测试驱动开发，：在设计课程时，先编写测试用例，然后再编写代码。这样可以确保你的代码符合预期，并且易于调试。好了，今天的课程就到这里。希望大家能够掌握这些设计高效Apex解决方案的策略，并在实际工作中灵活运用。如果有任何问题，随时提问哦！

查看详情

19

Multiple Triggers on the Same Object

第 347 页

同学们，今天我们来聊聊Salesforce中一个比较有趣但又有点棘手的话题——同一对象上的多个触发器。这个话题听起来可能有点技术性，但我会尽量用简单的话来解释，让大家都能明白。首先，我们来说说优点。其实，同一对象上的多个触发器并没有太多优点，更多的是缺点。但有一点可以提一下，那就是你不需要使用所谓的“交通警察模式”。这意味着你不需要特别安排触发器的执行顺序，它们可以相对自由地运行。此外，你还可以将触发器的逻辑分成“之前”和“之后”两部分，这样可以让代码更有条理。但是，缺点就比较多了。首先，最大的问题是，当你有多个触发器作用在同一个对象上时，Salesforce无法保证哪个触发器会先执行。这就好像你去参加一个派对，但没有人告诉你什么时候该跳舞，什么时候该吃饭，结果可能会很混乱。这种不确定性使得调试变得非常困难，因为你不知道哪个触发器导致了问题。其次，所有的触发器都共享同一组资源。这意味着如果多个触发器都在做类似的事情，比如查询数据库，那么它们可能会重复执行相同的查询，这不仅浪费资源，还可能导致你超出Salesforce的州长限制。州长限制是Salesforce为了防止系统过载而设置的一些规则，比如你一天内只能执行一定数量的数据库查询。如果你不小心超出了这些限制，你的应用可能会被暂时禁用。所以，同学们，虽然多个触发器听起来很方便，但实际上它们可能会带来很多麻烦。在设计你的Salesforce应用时，最好尽量减少同一对象上的触发器数量，或者使用其他方法来组织你的代码，比如使用“触发器框架”来更好地管理和控制触发器的执行。好了，今天的内容就到这里。希望你们能理解同一对象上多个触发器的优缺点，并在实际开发中做出明智的选择。如果有任何问题，随时问我哦！

查看详情

20

Principle: One Trigger Per Object

第 348 页

大家好，今天我们来聊聊Salesforce中的一个重要原则——每个对象一个触发器。这个原则听起来可能有点技术性，但其实很简单，就是建议我们在Salesforce中，每个对象只使用一个触发器。这样做的好处是，它可以帮助我们保持代码的整洁和易于管理。首先，让我们理解一下为什么会有这样的建议。想象一下，如果你有多个触发器在同一个对象上运行，那么当这个对象的数据发生变化时，所有的触发器都会被触发。这可能会导致一些意想不到的结果，比如触发器之间的冲突，或者性能问题。所以，使用一个触发器可以避免这些问题，使得我们的系统更加稳定和高效。但是，这里有一个例外，那就是当你使用第三方托管包时。这些包可能已经包含了它们自己的触发器，这时候你可能需要调整你的策略。接下来，我们来看看触发器的基础设置。一个常见的决策点是，触发器是否应该列出所有可能的上下文。这样做的好处是，它使得触发器更容易扩展，因为你可以很容易地添加新的逻辑。同时，这也可能鼓励开发者不要为每个小功能都写一个新的触发器。但是，这也意味着触发器在每种情况下都会被触发，这可能会带来一些额外的负担。另一个决策点是，我们应该使用什么形式的条件语句。使用单一的方法调用来处理After/Insert和After/Update事件，可以让代码看起来更加简洁。但是，如果你需要为不同的上下文添加新的业务逻辑，比如只针对After/Insert事件，那么你可能需要重新组织或重复一些条件语句。总的来说，每个对象一个触发器的原则是为了帮助我们更好地管理和维护Salesforce中的触发器。虽然在某些情况下可能需要做出一些妥协，但遵循这个原则通常会让我们的工作更加高效和有序。希望这些信息对你们有所帮助，谢谢大家的聆听！

查看详情

21

Example of Conditional Pattern for Easy Modification

第 349 页

今天我们来聊聊Salesforce中的触发器（Trigger）设计模式，特别是关于如何让我们的代码更易于修改和扩展。首先，想象一下你在写一个触发器，这个触发器会在记录插入或更新时执行一些操作。你可能会写出这样的代码： ```apex if (Trigger.isBefore && Trigger.isInsert) { // 在记录插入之前做一些事情 } else if (Trigger.isAfter && Trigger.isInsert) { // 在记录插入之后做一些事情 } else if (Trigger.isBefore && Trigger.isUpdate) { // 在记录更新之前做一些事情 } else if (Trigger.isAfter && Trigger.isUpdate) { // 在记录更新之后做一些事情 } ``` 这种写法看起来挺直观的，对吧？每个条件分支都对应一个特定的触发器事件组合。但是，如果你以后需要添加新的功能，比如在记录插入之后做一些额外的事情，你会发现你只需要在`After/Insert`的分支中添加代码，而不需要改动其他部分。这就是所谓的“易于扩展”。但是，如果你需要在`Before/Insert`上添加新的业务逻辑，你可能就需要修改现有的条件分支了。这可能会导致代码变得复杂，难以维护。那么，有没有更好的方法呢？专家们建议，我们可以预先为所有可能的触发器事件组合都写好分支，即使有些分支暂时是空的。这样做的好处是： 1. ，可重复使用性和通用性，：所有的触发器事件都被覆盖了，代码更加通用，可以在不同的场景下重复使用。 2. ，易于修改，：当你需要添加新功能时，你只需要在相应的分支中添加代码，而不需要改动现有的条件逻辑。这样，你的代码结构会更加稳定，修改起来也更加轻松。举个例子，你可以这样写： ```apex if (Trigger.isBefore && Trigger.isInsert) { // 在记录插入之前做一些事情 } else if (Trigger.isAfter && Trigger.isInsert) { // 在记录插入之后做一些事情 } else if (Trigger.isBefore && Trigger.isUpdate) { // 在记录更新之前做一些事情 } else if (Trigger.isAfter && Trigger.isUpdate) { // 在记录更新之后做一些事情 } else if (Trigger.isBefore && Trigger.isDelete) { // 在记录删除之前做一些事情 } else if (Trigger.isAfter && Trigger.isDelete) { // 在记录删除之后做一些事情 } ``` 这样，无论你以后需要添加什么新的业务逻辑，你都可以在相应的分支中添加代码，而不需要改动现有的条件结构。这就是为什么这种模式被称为“易于修改”的原因。总结一下，预先为所有可能的触发器事件组合写好分支，不仅能让你的代码更加通用和可重复使用，还能让你在添加新功能时更加轻松，不需要担心破坏现有的代码结构。希望这个讲解对你有帮助！

查看详情

22

How Should You Modularize Your Code?

第 350 页

让我们来聊聊如何在Salesforce中模块化你的代码。首先，想象一下，如果你的触发器里塞满了各种商业逻辑，那就像是在一个房间里堆满了各种家具，想要找到一件特定的东西会非常困难，对吧？这就是为什么我们要模块化代码。，模块化代码的好处，： 1. ，易于测试，：当你把代码分成小块，每块只负责一个功能，测试起来就简单多了。你可以单独测试每一块，确保它们都工作正常。 2. ，易于理解和维护，：模块化的代码就像是一本分章节的书，每章都有明确的主题，这样你或其他人以后想要修改或扩展代码时，就能快速找到需要改动的部分。 3. ，易于扩展，：如果你的业务需求变了，或者需要添加新的功能，模块化的代码结构让你可以轻松地添加新的模块，而不需要重写整个代码。 4. ，权限控制，：模块化还可以帮助你更好地控制用户的权限。你可以为每个模块设置不同的权限，确保只有有权限的用户才能执行特定的操作。，如何实现模块化，： - ，使用Apex类和方法，：将相关的商业逻辑封装在Apex类的方法中。这样，你的触发器只需要调用这些方法，而不是直接包含逻辑。 - ，使用接口和抽象类，：这可以帮助你定义通用的行为，让不同的类实现这些行为，从而提高代码的复用性和灵活性。 - ，分离关注点，：确保每个类或方法只负责一件事。比如，一个类处理数据验证，另一个类处理数据保存。，避免的问题，： - ，触发器中的商业逻辑，：这会让触发器变得复杂，难以管理和测试。把逻辑移到类中，让触发器只负责调用。 - ，难以阅读和维护的代码，：模块化可以让代码结构清晰，易于理解和维护。 - ，难以扩展，：模块化的设计让你可以轻松添加新功能，而不影响现有代码。总之，模块化你的Salesforce代码，就像整理你的房间，让每样东西都有其固定的位置，这样无论是使用还是维护，都会变得更加高效和愉快。希望这些建议能帮助你在Salesforce开发中更加得心应手！

查看详情

23

Principle: Keep Business Logic Out of Your Trigger

第 351 页

同学们，今天我们来聊聊Salesforce开发中的一个重要原则：让商业逻辑远离触发器。这个原则听起来可能有点抽象，但别担心，我会用简单的例子来解释。首先，想象一下交通警察。他们的工作是确保交通顺畅，而不是去修路或者设计交通信号灯。同样，在Salesforce中，触发器的主要职责是响应数据的变化，比如当一条记录被插入、更新或删除时。触发器的任务就是“指挥交通”，而不是去处理复杂的商业逻辑。为什么这么说呢？因为如果我们在触发器里塞满了商业逻辑，就像让交通警察去修路一样，事情会变得非常混乱。触发器会变得难以维护和调试，尤其是当你有多个触发器时，问题会变得更加复杂。所以，很多中小企业都建议，尽量把商业逻辑从触发器中剥离出来。你可以把商业逻辑放在其他地方，比如Apex类或者服务层。这样，触发器就只负责响应数据变化，而商业逻辑则由专门的类来处理。这样做的好处是，代码更清晰，更容易维护，也更容易调试。举个例子，假设你有一个触发器，在插入记录时调用一个方法`grantDirectorSharingAccess`。如果触发器是在插入操作时触发的，那么`Trigger.oldMap`会是空的，因为没有旧的记录。如果你不小心，可能会把空值传递给这个方法，导致错误。所以，我们需要确保在调用方法之前，检查一下`Trigger.oldMap`是否为空。总结一下，让商业逻辑远离触发器，就像让交通警察专注于指挥交通一样，可以让你的代码更清晰、更易于维护。你可以参考一些高级的触发器模式，比如我们刚才提到的那些链接，或者阅读Dan Appleman的《高级Apex编程》，来进一步了解如何更好地组织你的代码。好了，今天的课程就到这里，希望你们能理解这个原则，并在实际开发中应用它。如果有任何问题，随时问我！

查看详情

24

Should You Explicitly Pass Trigger Context Data?

第 352 页

让我们来聊聊Salesforce中的触发器和上下文数据传递的问题。首先，想象一下触发器就像是一个小助手，它在数据库中的某些操作发生时自动跳出来帮忙。比如，当你添加或修改一条记录时，这个助手就会开始工作。现在，问题来了：这个助手需要知道它是在什么样的环境下工作的，对吧？这就是所谓的“上下文数据”。有时候，我们需要明确地告诉助手这些信息，有时候则不需要。这就像是你去一个朋友家，有时候你需要告诉他们你带了什么，有时候则不需要，因为他们已经知道了。 Ryan，这里提到的一个人物，他会告诉你你的组织选择了哪种方式。这就像是在说，每个家庭（组织）都有自己的规矩，Ryan就是那个告诉你规矩的人。在不同的类中重用方法，这就像是你有一个工具箱，里面的工具可以在不同的项目中使用。如果你能让这些工具在不同的情况下都能工作，那么你的工作就会更高效。这就是为什么有时候我们选择不传递具体的值，而是让方法自己去“感知”它需要的信息。隐性使用需要选角，这听起来有点复杂，但其实很简单。就像是在电影中，有时候演员需要扮演不同的角色，但他们不需要每次都重新学习如何表演。他们只需要根据剧本（上下文）来调整自己的表演。最后，记住，这只是一个讨论的幻灯片。每个人都有自己的看法，但重要的是，学生们应该知道他们不必总是传递具体的值。有时候，让方法自己去“感知”环境，会让代码更加灵活和可重用。所以，总结一下，是否传递触发上下文数据，取决于你的组织和你想要达到的目标。有时候传递是必要的，有时候则不是。关键是找到最适合你情况的方法。

查看详情

25

Module Agenda - 353

第 353 页

同学们，今天我们来聊聊如何在Salesforce中设计高效的Apex解决方案。这个模块的内容非常实用，尤其是当你需要处理大量数据时，掌握这些策略会让你的工作事半功倍。首先，我们来看，高效使用数据库，。在Salesforce中，数据库操作是非常关键的。每次你查询或更新数据时，都会消耗一定的资源。所以，我们要尽量减少不必要的数据库操作。比如，尽量避免在循环中进行查询或更新操作，因为这样会导致多次访问数据库，效率很低。相反，你可以先把数据批量查询出来，然后在内存中进行处理，最后再批量更新回去。这样不仅能减少数据库的访问次数，还能提高整体的性能。接下来是，设计触发器，。触发器是Apex中非常强大的工具，但如果不小心使用，可能会导致性能问题。一个好的做法是，尽量让触发器保持简洁，专注于单一职责。比如，一个触发器只处理一种类型的操作（如插入、更新或删除），并且尽量避免在触发器中写复杂的业务逻辑。你可以把这些逻辑放到辅助类中，这样不仅能让触发器更清晰，还能方便以后的维护和测试。最后，我们谈谈，设计课程，。这里的“课程”其实是指你如何组织和规划你的Apex代码。一个好的设计模式是，把代码分成不同的层次，比如数据访问层、业务逻辑层和用户界面层。这样可以让你的代码更加模块化，易于维护和扩展。另外，记得多使用注释和文档，这样不仅你自己以后能看懂，别人接手你的代码时也能快速理解。总结一下，设计高效的Apex解决方案，关键在于，减少数据库操作，、，合理设计触发器，和，模块化代码结构，。掌握了这些策略，你就能在Salesforce开发中游刃有余了。好了，今天的课程就到这里，希望大家能把这些技巧应用到实际项目中。如果有任何问题，随时问我！

查看详情

26

Principle: Modularize Business Logic

第 354 页

让我们来聊聊业务逻辑模块化的一个重要原则——OOP（面向对象编程）实践。这个原则听起来可能有点技术性，但其实很简单，就是让我们的代码更加清晰、易于管理和重用。首先，我们来说说“如果不需要实例，静态会有所帮助”。在编程中，有时候我们写的方法并不需要依赖于某个特定的对象状态。比如，一个简单的数学计算，像加法或乘法，它们不需要知道任何关于对象的信息，只需要输入数字就能工作。这时候，我们就可以把这个方法设为静态的。这样做的好处是，我们不需要创建对象实例就能直接调用这个方法，既节省了资源，又让代码更简洁。接下来是“打破方法”和“简短的专业方法”。这里的“打破方法”并不是真的把方法打碎，而是指我们应该把复杂的功能拆分成多个小方法。每个小方法只负责完成一个具体的任务。这样做的好处是，每个方法都变得简单明了，容易理解和测试。而且，如果我们需要修改某个功能，只需要改动相关的小方法，不会影响到其他部分。再来说说“一个方法应该做一件事，只做一件事并且做好”。这是OOP中的一个核心原则。想象一下，如果一个方法既要处理数据，又要发送邮件，还要更新数据库，那么这个方法的职责就太多了。一旦出现问题，我们很难快速定位问题所在。所以，我们应该让每个方法只专注于完成一个任务，这样不仅代码更清晰，也更容易重用。最后，我们来看一个实际的例子。假设我们有一个网页，页面上有多个子菜单。我们想要突出显示第一个子菜单。按照我们刚才讲的原则，我们可以写一个专门的方法来完成这个任务。这个方法只负责找到第一个子菜单并改变它的样式，而不需要关心其他子菜单或页面的其他部分。这样，如果以后我们需要修改突出显示的样式，只需要改动这个方法就可以了。总结一下，业务逻辑模块化的要点就是让我们的代码更加模块化、职责单一、易于管理和重用。通过遵循这些OOP的最佳实践，我们可以写出更高质量的代码，让我们的工作更加高效。

查看详情

27

Considerations Around Trigger Batches

第 355 页

让我们来聊聊Salesforce中的触发器批处理注意事项。首先，想象一下你有一堆记录需要处理，Salesforce会把这些记录分成小批次，每个批次最多200条记录。这就是我们说的“200”原则。现在，这里有个小问题：这些记录的处理顺序是不可预测的。就像案例00026950中提到的，你不能确定哪条记录会先被处理。所以，在设计触发器时，你不能依赖于记录处理的顺序。接下来，我们来看看“一次一个”的原则。Salesforce会一次处理一个批次，而不是同时处理多个批次。这意味着你的触发器需要能够处理一个批次中的所有记录，而不是依赖于多个批次同时处理。最后，我们回到“相同的原则”。无论你处理多少个批次，每个批次都遵循200条记录的限制，处理顺序不可预测，并且一次只处理一个批次。现在，让我们把这些原则应用到你的触发器设计中。你需要问自己：我的触发器设计应该预期处理多少条记录？答案是：你应该始终考虑到多批次的情况，因为Salesforce会分批处理记录。动画1会告诉你：通过触发器发送记录的顺序是否可以预测？答案是不可以。你无法控制记录在批次中的出现顺序或批处理的顺序。动画2会展示：批次是一次处理一个还是并行处理？答案是一次处理一个批次。最后，动画3会解释：这如何应用于课程？由于触发器最佳实践建议使用类来处理业务逻辑，因此实际上需要处理批处理记录的是类及其方法。这意味着你应该把复杂的逻辑放在类中，而不是直接在触发器中处理。希望这些解释能帮助你更好地理解Salesforce中的触发器批处理注意事项。记住，设计触发器时要考虑到这些原则，以确保你的代码既高效又可靠。

查看详情

28

Key Takeaways - 356

第 356 页

让我们来聊聊Salesforce开发中的一些关键要点，这些要点能帮助你写出更高效、更可靠的代码。首先，，查询前收集数据，。这意味着在你执行任何操作之前，先收集好你需要的所有数据。这样可以避免在代码执行过程中频繁地去查询数据库，减少不必要的资源消耗。其次，，在执行TLR（Trigger Logic Runner）操作之前收集数据，。TLR是Salesforce中用来处理触发器逻辑的工具。在执行这些操作之前，确保你已经收集了所有必要的数据，这样可以避免在执行过程中出现数据缺失或错误。接下来，，使用每个对象一个触发器原则，。这意味着每个对象（比如Account、Contact等）应该只有一个触发器。这样可以避免触发器之间的冲突，也更容易管理和维护代码。，让业务逻辑远离触发器，。触发器应该只负责处理数据的插入、更新、删除等操作，而业务逻辑应该放在Apex类中。这样可以让代码更加模块化，也更容易测试和维护。，始终设计触发器和类方法来处理批量输入，。Salesforce中的数据操作通常是批量进行的，所以你的代码应该能够处理多条记录，而不是单条记录。这样可以提高代码的效率，也能避免超出系统限制。，循环的SOQL可以帮助你的代码避免超出限制，。SOQL是Salesforce中的查询语言，如果你在循环中执行SOQL查询，可能会导致超出查询限制。为了避免这种情况，你可以使用循环来分批查询数据，这样可以减少每次查询的记录数，避免超出限制。接下来，我们来看看需要避免的一些做法：，在循环内卸载，。这意味着不要在循环中执行复杂的操作，比如调用外部服务或执行大量的计算。这样会导致性能问题，甚至可能超出系统限制。，循环内部的TLR，。同样地，不要在循环中执行TLR操作。这会导致触发器被多次触发，增加系统的负担，也可能导致数据不一致。总结一下，这些关键要点可以帮助你写出更高效、更可靠的Salesforce代码。记住，在编写代码时，始终要考虑批量处理、避免不必要的查询和操作，以及将业务逻辑与触发器分离。这样不仅能提高代码的性能，还能让代码更容易维护和扩展。

查看详情

DEX450

课程介绍

课程章节