In this course, you’ll learn about the benefits of engineering your Apex code with a layered architectural approach to help ensure a strong foundation to support enhancements and maintenance over time.
Play by Play is a series in which top technologists work through a problem in real time, unrehearsed, and unscripted. In this course, Play by Play: Understanding Apex Enterprise Patterns and Separation of Concerns in Salesforce, Peter Tempfli and Don Robins explore maximizing the benefits of coding, reuse patterns, and decoupled business logic by carefully crafting libraries of classes that together comprise an architecture that will reduce code breakage and promote both clarity of purpose and developer efficiency. Learn about Apex Enterprise Patterns, explain how and why developers should adopt a separation of concerns architecture for their Apex code, and clarify the differences between frameworks and patterns.
By the end of this course, you’ll have gained some valuable insight into how to apply these tried and true software development patterns to design and build your own robust, reusable, and scalable Apex architecture.
Don Robins is a well known Salesforce MVP, instructor, author, and speaker.
A custom business application developer for more decades than he cares to
admit, he focuses on Salesforce technical instruction and knowledge
Section Introduction Transcripts
Section Introduction Transcripts
Course Overview Welcome to this Salesforce Play by Play with Pluralsight. Salesforce Play by Play is an interactive series where we sit down with Salesforce experts such as MVPs, consultants, developers, and architects to discuss common challenges faced every day by Salesforce customers. We'll be learning while discussing concepts and debating trade-offs on various approaches to solving real-world problems. We learn by reviewing system configurations or writing code, and then exploring the benefits of any particular solution. In this course, we challenge Peter Tempfli, lead developer for blackthorn. io, to help us understand Apex enterprise patterns, and to explain how and why developers should adopt a separation-of-concerns architecture for their Apex code. First, Peter defines just what a concern is. He explains what it means to separate concerns in an application as he introduces us to some common use cases that can benefit from an SOC approach. Next, he describes the basic layers that are partitioned as the distinct concerns in the Apex Enterprise Patterns framework, and how they're implemented as Apex classes. He walks us through examples of three primary layers, the services layer, the selector layer, and the domain layer, and he demonstrates how they work in a specific implementation of a simple reference application. Along the way, we discuss the use of naming conventions for classes and methods, clarify the differences between frameworks and patterns, and explore how developers can apply just those aspects of these patterns as needed by their own implementations. By the time we're done, you'll have gained some valuable insight into how to apply these tried and true software development patterns to design and build your own robust, reusable, and scalable Apex architecture. So whether you're a beginner, intermediate, or advanced Apex developer, please join us for Understanding Apex Enterprise Patterns and Separation of Concerns in Salesforce. We hope you enjoy it.
Introduction to SOC Layers Okay, so you already mentioned the entry points and the database, so let's talk about the entry points. So, Salesforce can have a lot of entry points. These are the different execution contexts are they not? Yes, they can be different execution contexts, so a web service is different execution context if you compare to Batch or scheduled jobs, or triggers, for example. So, these entry points, if these entry points call service layer methods, all of the entry points call the same service layer methods, it makes things a bit easier to maintain and organize because we exactly know what is happening, and we know that the same thing is happening in every context.