function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
JasonMcGeeJasonMcGee 

Creating a class for data manipulation

Would there be any downside to creating a seperate class from your controller to handle the data manipulation?

 

for example:

public class DataLayer { public void updateList(List<SObject> aList) {update aList;} }

 

 

This new class could either be abstract or an inner class,

 

basically it would serve the purpose of moving all data interaction through a class (layer) so you could do quick trigger like things without creating triggers

 

Does this approach cause any type of issue or problem?  I am not asking if it is redundant, just if there is anything wrong with doing it that way.

 

Thanks.

 

Best Answer chosen by Admin (Salesforce Developers) 
JonPJonP

The issues is not refactoring code out of your controller to other classes--that's a good idea if multiple controllers or classes need to share the same logic.

 

But can you do away with triggers altogether?  Your data could be manipulated in non-UI ways, such as through the API or a custom web service.  A trigger will catch the insert/update/delete event, but your controller may not.

 

That said, if you've created a common set of classes for making data changes, you could call them from a controller or trigger or web service and get the same behavior, which is a great example of code reuse.  Just make sure you aren't call the same code twice--once from a controller/web service, and then again from a trigger fired by data operations performed by the controller/web service.