Design considerations for a service layer architecture

I’m working on a current project that implements a service-layer architecture (e.g. There’s the database(s), then a data service layer, then a service layer, and then finally your API controller code).

Because the code has been designed to create business object classes, each business object has it’s own service class (e.g. User business object has a UserService class).

Originally when I started using this design, I understood that the API controller was sort of an “entry point” into the code, and that the bulk of the processing and functionality was to be done within the service class (and then funnelled through to the data service layer if required).

After some discussions with a senior developer on my team, I have learnt of a different approach where the following rule is considered for every public method in the service class

  1. It must be needed by another related component

It therefore made sense to me that, if I had a method that only the controller needed, then the controller should be the one to handle it. By doing this, I was able to remove a lot of communication from the controller to the service and in turn, clear up a lot of code clutter.

In the end, I had a much clearer and direct process.

 

Subscribe

0 comments