https://ceptes.com/wp-content/uploads/2023/01/img-floater-3.png
https://ceptes.com/wp-content/uploads/2022/12/img-floater-2.png

Blog

bt_bb_section_top_section_coverage_image

How to Manage Dependency Injection within Salesforce

September 23, 2020by Ananya Mohapatra

If you don’t know what Dependency Injection is, why it is required, which problem does it help us resolve, and how Dependency Injection is used in Salesforce, then don’t worry; by the end of this article, you will be clear of all your doubts.

Dependency InjectionWhat is Dependency Injection (DI)?

Dependency Injection is a design pattern that provides inversion of control; it is used for breaking tight coupling between 2 objects. It is an alternative approach to binding two objects loosely. 

Let us understand this with the help of an example.

Why is Dependency Injection required?

Let us consider the example of the client consuming the services provided by a server.

Typically, the server would be instantiated by the client as below:

Server s = new Service ();

s.Print();

Yet, the above code introduces a dependency between the Client and Server, and the client is tightly coupled with the server, as seen in the below diagram. 

You can see the implications of this dependency by trying to delete the Service, which is not possible as the client uses it.

So, what do you think are the issues with the above type of binding?

  1. The flexibility is reduced
  2. It is difficult to make changes
  3. It is not easy to reuse the code

DependencySo, we prefer to use Dependency Injection for flexibility, extensibility, and reusability of code.

Let us now see how Dependency Injection is managed in Salesforce;

In Salesforce, there are two types of dependencies possibilities.

  1. Introduced due to coding
  2. Dependency between metadata formed by using declarative tools (process, flow, layout, and actions)

Dependency injection helps in forming dependencies at runtime instead of explicitly during development. It aims to break the dependence between the calling code and how an instance is created. 

In the above example, we saw that the client had access to the Server implementation. The solution would be to invert the control, such that the client does not know about the server implementation details. 

The use of the “new” operator needs to be avoided to use Dependency injection, since the usage of a “new” operator requires packaging and deploying the Server implementation along with the client, resulting in loss of extensibility.

The goal of Dependency Injection is to eliminate the need for the calling code needing to know how an instance is obtained; it only needs to know how to use it. Through dependency injection, multiple different implementations could be packaged and deployed.

A dependency exists in the above example because the compiler needed to know the Service class of the client. 

The compiler needed to check whether the Service class compiles; the aim is to remove this dependency. This is possible if we load the Service class at runtime. An injector class would be required to load and provide the required service implementation class. 

The need for an Interface. To achieve loose coupling, we need to design the code to interact with an interface rather than an implementation. The implementation of the interface would vary from customer to customer. 

Dependency Injection uses configuration and code to dynamically determine the implementation used, thus decoupling dependencies from where they are used, as seen in the diagram.

Dependency managementTo Summarize

We saw what Dependency Injection is, the issues observed if Dependency injection is not used, the different types of Dependency Injection, and how to break down tight coupling and replace it with loose coupling using Dependency Injection within Salesforce.

The pros and cons of Dependency Injection are as below:

Pros: 

  1. Breaks the tight-coupling as it causes issues with reusing, updating, and maintaining the code.
  2. Adds support for many optional implementations that can be selected at runtime without code modifications.

Cons:

  1. Introduces complexity in the architecture as it is challenging to identify implementations corresponding to associated calls.
  2. Difficult to troubleshoot in case something breaks at execution. Delay in identifying runtime issues.

CEPTES is a Salesforce partner with 10+ years of ecosystem expertise & over 80% Salesforce certified consultants. We are widely accepted as a leader in delivering Salesforce Cloud (Sales Cloud, Service Cloud, Marketing Cloud, App Cloud, etc.), Salesforce Analytics, and Lightning Migration services to various industries and companies of different sizes & types.

If you are looking for Certified Salesforce consulting services, then contact us today!