0

In REST Web Service, is having 3 layers - Controller, BO (Service) and DAO a standard way? Why do we need a separate BO layer. Why not to write our logic in Controller class which, calls different DAO classes ??? So, basically I want to have all JAX-RS annotations like -

@GET

@Path("/{parameter}")

@Produces("application/json")

in Controller interface and only root @Path in Controller implementation. I don't want to unnecessarily have another layer of BO. I want to reuse code by calling the Controller classes itself from other Controller classes. I know the classes are annotated but that's for JAX-RS runtime to handle it appropriately. Can I still instantiate those Controller classes and call different methods from other Controllers???

Puneet Pandey
  • 960
  • 2
  • 14
  • 28
  • Suppose you have a web application, Restful Web Service, SOAP Web Service, some RMI invocation service, etc. that you want to expose to talk to your application, how will you achieve that if all your logic is in 1 controller class? – Buhake Sindi Jun 10 '15 at 07:26
  • but we dont really expose code - it is a URL which is exposed. Client calls that URL...Now, I write my code in Controller or in Service layer is not really a concern - neither to me nor to my client. – Puneet Pandey Jun 10 '15 at 07:32
  • Restful Web Service has it's own controller. Web Applications has its own Controller, SOAP Web Service has its own controller. Neither of these controllers are shared amongst each other. So, you're telling me you want to duplicate code to each of the controllers? That breaks the "code reuse" design principle. – Buhake Sindi Jun 10 '15 at 07:35
  • 2
    I'm voting to close this question as off-topic because this is not a programming question, but an (rather opinion based) architecture question (it could be a fit for programmers.se after editing the question as per the site's rules). – BalusC Jun 10 '15 at 08:41
  • @BaluC I edited my question. To me it's a programming question. I am dealing with different JAX-RS annotations and want to treat those annotated classes as normal java classes only instantiate and call different methods. please let me know if want me to provide more information. – Puneet Pandey Jun 10 '15 at 09:01

2 Answers2

1

I see two main reasons :

  1. Separation of concerns
  2. Reusability : Many controllers might need to use the same business logic
couettos
  • 591
  • 5
  • 15
  • Yes, a valid point. But why not to have a utility class to separate our common concerns. – Puneet Pandey Jun 10 '15 at 07:34
  • 2
    well, I think this utility class you talk about can become huge, and essentially, will become your BO. Also, you might realize it is common long time after you code it. It is a good practice to split your logic into many classes. example "UserService", "ItemService" etc... – couettos Jun 10 '15 at 07:37
  • I mean - a utility class only to put common concerns and not to unnecessarily create a different layer altogether just to put logic which is not usable from anywhere else. – Puneet Pandey Jun 10 '15 at 07:41
  • @PuneetPandey, have a look at an **example** in my answer. – Naman Gala Jun 10 '15 at 07:43
  • Yes, one might realize the common usability of a method late in development life-cycle. – Puneet Pandey Jun 10 '15 at 07:44
  • 1
    You never know, which part of code will be used by another functionality, if it is layered properly then it can be used directly. Also keep in mind that maintenance of layered project is easier because of less redundancy. – Naman Gala Jun 10 '15 at 07:48
  • @Naman - Yes, re-usability of common concerns looks to be a strong reason to a have a different Service layer. – Puneet Pandey Jun 10 '15 at 07:48
  • I once work on a project where all the business logic was done in the controllers, using "DTO". It was fun when we had to plug-in a new client using different data structure for the DTOs – couettos Jun 10 '15 at 07:52
0

To separate business logic from controller, as DAO only interact with database, so it does not contain any business logic ideally.

You can consider the business logic being used by multiple modules like controller, rest service, SOAP service etc.

Example: Suppose you have an add functionality and you want it to work from GUI as well as SOAP service. If you write your business logic (of validation, conversion, calculation etc) in controller then you will have to rewrite it for SOAP service also. Which will result in redundancy and you will not be able to reuse your code.

For updated question:

In the starting phase of development it looks ok to include things at one place, but as time passes code becomes so large that it creates problem to manage the code. In your case, consider you are using one controller inside another controller. In future it might create cyclic dependency among controllers.

Example: ControllerA requires a functionality present inside ControllerB. ControllerB requires a functionality present inside ControllerA. So in this case both are dependent on each other. So it will be difficult to understand the code flow. And also at the time of Injection this will create problem.

Naman Gala
  • 4,670
  • 1
  • 21
  • 55
  • @PuneetPandey you can refer [this](http://stackoverflow.com/questions/4821130/modules-vs-layers-in-java-package-structure) and [this](http://stackoverflow.com/questions/6260302/program-design-package-by-feature-vs-layer-or-both) SO question and see how code is separated. – Naman Gala Jun 10 '15 at 07:52