Improve selector architecture to allow for different object types and sources #10
Replies: 2 comments 1 reply
-
Would you plan to modify the existing Selector classes (and keep the "Selector" nomenclature), or implement some type of a Repository that uses Selectors when accessing the database? |
Beta Was this translation helpful? Give feedback.
-
Hi @kenlewis-sfdo, Yes! Now that the AEP repo has accepted the new domain structure I plan to move forward with this selector. When I write a service method and I need a data set at some point, I am not interested in where this data is coming from, I just want the data. I will probably do something similar as I did with the Domain, and introduce a new interface named fflib_ISelector, and that the existing fflib_SObjectSelector is just one of the implementations. If you want to contribute with this effort I am happy to discuss this further with you! |
Beta Was this translation helpful? Give feedback.
-
The selector should be redesigned so that it is not coupled to a database. In this new architecture the selector will retrieve data from wherever it is stored. It should not be the concern of a service class calling the selector to know where the data is coming from.
This new architecture should allow for getting the data from;
In memory from previous queries (Identity Map Design Pattern)
A Platform Cache
The Database
External WebService
The queries should also be able to roll-over. Like when the requested record is not in memory, then the next selector in line should be called as the record might be in the Platform cache. If it is still not found the record can be queried from a database.
Beta Was this translation helpful? Give feedback.
All reactions