search

Coding-With-The-Force / Salesforce-Separation-Of-Concerns-And-The-Apex-Common-Library

This repo hopes to better explain Separation of Concerns for Salesforce and how to leverage the Apex Common library to employ it in your org.
88 stars 19 forks source link

Composite Services and IOC #6

Open rwtaylorjr opened 2 years ago

rwtaylorjr commented 2 years ago

Most of the examples i've seen of the Service layer using enterprise design patterns are where the service layer is orchestrating one or more domain or selector objects. I haven't seen any examples of an enterprise layer orchestrating services. I know an instance of a Service could easily be constructed which self populates its dependencies...but that violates IOC (inversion of control) principles. Seems like you would need some entity responsible for providing DI (dependency injection) which manages the dependency mappings. Because as it stands, the Application class doesn't appear to support this concept.

For example, suppose the Task_ServiceImpl.class depended on one or more other services...then the approach below would not support proper IOC.

public static final fflib_Application.ServiceFactory service = new fflib_Application.ServiceFactory(new Map<Type, Type>{ Task_Service_Interface.class => Task_Service_Impl.class })

Are there plans for supporting this concept?

rwtaylorjr commented 2 years ago

Actually, i think i'm being too rigid. The Service class .newInstance() could orchestrate the DI via the Application Class. Prior to testing you could inject the appropriate mocks into the Application class instance....Coming from Java/Spring, i'm just used to the actual DI being completely managed by a separate entity via annotations....but i see that the end result could be achieved in the manner described above using the Application class.

Would still love to hear any feedback on this approach to Orchestrating Services