You need to sign in to do that
Don't have an account?
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.
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.