Dependency Injection with the Force DI Framework

Editor's Notes

• #6: Key MessageSalesforce is a publicly traded company. Customers should make buying decisions only on the products commercially available. Talk TrackBefore I begin, just a quick note that you should base your purchasing decisions on products and services that are currently available.
• #8: https://stackoverflow.com/questions/14301389/why-does-one-use-dependency-injection Often code classes depend on each other, such as an Apex controller depending on another Apex class to log metrics and information. Overtime, you create many Apex classes that use the same logger, which persists the metrics to a custom object. Later, you decide you want to log the metrics to a third-party system rather than a custom object. To make this change, you need to search and replace your code base and re-deploy your app. Later, you decide you need to log via http callouts in some places, to log via platform events in other places, and to make testing easier to use mock loggers in yet other places. Dependency injection is a design pattern that decouples code from its dependencies by following a couple key principles: Code to interfaces (abstractions) rather than referencing implementation classes directly Use a service locator to look up dynamically and inject the appropriate interface implementation, whereby the actual implementation can be swapped out via simple configuration settings and no code changes There also exists declarative dependencies such as when a custom button depends on a specific Visualforce page or Lightning component to invoke.
• #9: https://stackoverflow.com/questions/14301389/why-does-one-use-dependency-injection When you first develop an application, you begin with your requirements and everything you put into the app has a known purpose. All the parts and pieces have their place and the app ”just works”.
• #10: https://stackoverflow.com/questions/14301389/why-does-one-use-dependency-injection Overtime, however, you may receive new requirements that build on top of or contradict the original design. Like playing the game Jenga, refactoring the app to support these changes can be tough. Depending on the architecture, such as tightly coupled code, then making changes can be difficult and potentially cause breaking changes. The more tweaks to the code to try and bend original design to new requirements often leads to messy code. Dependency injection is a design pattern to try and mitigate those risks by using architectures that are loosely coupled and implementation details can be swapped out in a more of plug-n-play manner without causing significant changes to other parts of the code base.
• #11: Animations: Click to show bottom orange rectangle around message classes Click to show top orange rectangle around chat app Click to show the apex debug code output We start with three simple classes, ChatApp, WorkingMessage, and VacationMessage. There is nothing inherently wrong with this design. Firstly, do note that ChatApp is tightly coupled to both the WorkingMessage and VacationMessage classes. If the message classes change, then that likely will require changes to ChatApp. Secondly, for the ChatApp class to compile, then both the messaging classes must also exist in the same org. Thirdly, to change out what message is used when the user is in or out of office requires the Apex classes to be updated and re-deployed.
• #12: Animations: Click to highlight the IMessage interface in lower region of slide Click to highlight the IMessage usage in ChatApp Click to highlight the ChatApp constructor Our first refactoring step is to introduce an interface, IMessage, and update the WorkingMessage and VacationMessage classes to implement it. Next, we update ChatApp’s greetings() method to code against the interface rather than knowing the specific implementation class. In this manner, we have decoupled the greetings() method from the details. In this example, we have moved the logic for determing the message implementation to use into the constructor, a logical next step would be to either modify the constructor to accept an IMessage argument (this is known as constructor injection) or have the constructor use a service locator to look up the implementation to use. Either way, the next step is to decouple the ChatApp entirely from knowing about the IMessage implementations and only know about the interface (the abstraction).
• #13: In this example, we have moved the logic for determing the message implementation to use into the constructor, a logical next step would be to either modify the constructor to accept an IMessage argument (this is known as constructor injection) or have the constructor use a service locator to look up the implementation to use. Either way, the next step is to decouple the ChatApp entirely from knowing about the IMessage implementations and only know about the interface (the abstraction).
• #14: In this example, we have moved the logic for determing the message implementation to use into the constructor, a logical next step would be to either modify the constructor to accept an IMessage argument (this is known as constructor injection) or have the constructor use a service locator to look up the implementation to use. Either way, the next step is to decouple the ChatApp entirely from knowing about the IMessage implementations and only know about the interface (the abstraction).
• #15: Animations: 1. Click to show the textbox Let’s step back from the code for a minute and talk about what we have developed with our refactoring efforts. In the orange box, we have our ChatApp with a greetings() method and an IMessage property that refers to an interface in the blue box. In the green boxes, we have two implementations of the IMessage interface that can be injected into the ChatApp. Designing your apps to code to interfaces (abstractions) is the first step to decoupling dependencies from the code that uses them.
• #16: Because ChatApp’s operations do not specifically refer to the message implementations, then we can add/update/remove green boxes without causing code changes to the orange box (our application).
• #17: Then, for even more flexibility in our app’s design, we can dynamically determine the implementation class to use with a dependency injection framework that either looks up the class to use in configuration or runs custom Apex logic to determine the class the use.
• #18: Animation: 1. Click to highlight the bottom message classes Let’s come back to the code again and begin to think about the benefits this design has when we look to packaging our app.
• #19: Because our ChatApp is decoupled from the VacationMessage and WorkMessage classes, they can each be developed and live in their own packages. The ony common dependency among them is a base package with the IMessage interface.
• #20: Animations: Click to show sandbox cloud Click to show green line draw to sandbox Click to show orange line draw to sandbox Click to show purple line draw to sandbox Click to show CMDT text box For development purposes, we could have different teams working on the separate packages in their own scratch orgs. Then when ready to do some integration testing, they can install their packages into a sandbox. Use a dependency injection framework or similar logic to then look up and inject into ChatApp the desired message implementation class.
• #21: https://github.com/afawcett/force-di
• #22: Demo 1: The ChatApp example discussed in the slides Open developer console and show the refactored code using the force-di framework Create a CMDT record to wire up VacationMessage as the message class to inject Run anonymous apex to show the debug output printed the out of office message Update the CMDT record to wire up WorkingMessage as the message class to inject Run anonymous apex to show the debug output printed the in the office message Demo 2: Object Action Override with Lightning component In Object Manager, show the Widget__c object’s View action overridden with a lightning component Open developer console to show the WidgetNewCmp using the <c:di_injector> tag Create a CMDT record to wire up VacationMessage as the message class to inject Demo 3:
• #24: End Slide