Suppose I have a Spring application divided into 3 layers: controller, service and repository. In which layer should all the business logic go? From what I have read on the net, the controller should only consume the service and it is the service that should be the one that contains all the business logic. Is this correct? Should I handle the Exception that may occur in the service?, I'm quite new to Spring and not sure which is the correct way to approach and which are the best practices.
Into services.
Repo - interaction with database
Controller - Http communication handling (or other type if interaction like CLI)
Service - bussiness logic.
You should put all your business logic into the Service Layer.
Commonly, exceptions are, also, handled at the Service Layer. This happens mainly because of the reusability. However, in Spring Applications, generally, even the service layer throw the exceptions, so that you can centralize all the errors in a single handler class.
Read more at Spring MVC Exception Handling.
Related
I'm developing a set of microservices for a web application with Spring Boot, and I'm unsure if the pattern design I'm using is correct, or makes sense, or has any advantages.
What I'm using is a controller-facade-service design, which in my mind should work in this way:
The controller delegates everything to the facade, passing the input DTO to it
The facade implements all the business logic and uses one or more services to create an output DTO to send back to the controller
Services implement core and atomic functionalities, mostly CRUDs, without any or minimal business logic so that different facades with different business logic can use them, and return a JPA entity to the facade
Is this a good design pattern? Is the facade unnecessary?
More specifically, should the business logic be in the facade or in the service? I believe services should be logic agnostic so that they can be shared across multiple facades, which may implement different logic depending on the endpoint.
Also, in the case of a CRUD operation, should the service return an entity to the facade? Or should it be up to the service to create an output DTO for the facade?
It feels comparatively easy to implement a bunch of classes that will eventually be part of a UI and need to be persisted without dealing with things like Hibernate or Spring and then, once tested and working in unit and integration tests, add in Hibernate and Spring later. In fact, I think maybe that is the correct approach. But is it realistic? If you know from the outset that a class would have to be persisted and indeed multiple classes which have complex relationships have to be saved to a database, would that not in practice affect the design? Or can you actually just get all the logic working, ignoring the eventual persistence and UI and add it in later?
You mentioned developing without UI and persistence layer. Then the only layer of prominence which remains is Service layer.
If you are going ahead with implementing only the service layer its NOT a bad idea. Reason, now-a-days there are many RESTful services. They do not have a UI. But on the other hand they do have persistence. However, the process of exposing them as RESTful services,determining their input/output format(JSON schema mostly) and testing their integration with any other system can still be done without a persistence layer.
This is not to say that your service layer will also be exposed as RESTful service. Even if it is not - while implementing your services you need to -
design your service granularity(fine or course)
design your DTOs(Data Transfer Objects) which will be responsible for carrying data from UI layer to service layer where they will be converted to domain objects(but this conversion to domain classes can wait till you implement persistence)
unit test your service classes and make sure business logic is implemented correctly
Considering there are a lot of things that can be done without a UI & persistence layer - I would say go ahead - design and even start implementing.
But keep in mind only one caveat - keep some buffer integration time when you integrate your service layer with UI & persistence layers.
I want to develop an enterprise level application using spring MVC in presentation layer and spring in Business Logic Layer and hibernate in data access layer.
But i want to keep the presentation layer in a web server, multiple business logic layer in multiple server and data access layer in another physical server that means i want to establish a n tier solution using spring mvc.
I am able to separate the layer in my architecture. But the problem is my solution is just work on a single server. I cant do a architecture for multiple physical server.
Suppose that, from controller i use #Autowired annotation to inject the object of business logic layer. But how can i establish a system where controller talks to business logic layer over the network and business logic layer talks to data access layer over network as well.
If anyone can describe the solution in details then it would be very helpful for me.
Thanks...
You should be able to divide your code quite easily. Let's call your data access layer a "Data Provider" service and business logic layer "Business Service".
Now, you have to decide what kind of network protocol are you going to use.
These days REST is the most popular one and also it is very easy to setup your REST endpoints with Spring MVC (use #RestController on the server and RestTemplate on the client). You can also use RMI if you want to really couple your services (Data Provider and Business Service) using the same Java code (interfaces, DTOs etc.)
I have a design/architectural problem:
I've started developing a java web application. I thought of using 3 layers: a persistence layer (with jpa and hibernate), a business layer and a presentation layer. My problem now is:
the jpa entities would make the model but can or may I use the entities as business objects?
Is this a practice? My common sense says I shouldn't, but then, I need to duplicate these entities as business objects?
Finally, I'd like the presentation layer to be really decoupled from the other layers. While using spring mvc with jsp at first, I'd like. if it's suitable, at some moment to switch to javascript-based application that communicates with the backend through rest requests.
Yes, you can. Outside the persistence context, the JPA Entities are like simple POJOs. It is legal to use them in business code (actually, as hinted by JB Nizet, you usually ALWAYS use them in your business layer without DAO). If it is tightly related to the Entity, you can even add business logic into your JPA beans. Nevertheless, it will be harder to read and understand what the code does. But if you have a reason to do that - there is nothing illegal. It all comes down to software design practices and what you need most.
When you want to change your app into the REST-powered service, it is not difficult. You will have to change the Servlet you are currently running your app with for a JAX-RS or other framework Servlet which will handle HTTP requests in a REST manner for you. It is done in web.xml. Then, you will place your html-pages in any place, where it is accesible for the remote hosts, and connect them to your REST-service with the Javascript AJAX or sth. You should take care of CORS then.
I have been using spring security with #PreAuthorize on my controller methods. My reasoning was that I wanted the authorization check to happen predictably in one layer, and as early as possible in the request. However, I just read the spring security 3 documentation, and saw that they recommend applying method level security on the service layer (but they don't say why).
My question is: should spring security method level annotations be applied at the controller layer or the service layer? (Or "both", or "it depends"?) More importantly: why?
"It depends" :). If your application has a service layer through which all your business logic is applied then that is usually a clean place to apply your security constraints and be certain that you haven't missed out any corner cases.
Web code is generally messier, there's more of it, it changes more rapidly and you may end up calling the same service methods from multiple places. Someone might add a new controller and forget to secure it properly. Alternatively you might have different types of clients calling the same services.
But it depends on how your application is structured and what your use cases are. You may have a good argument for why you want to secure a controller.
Think in terms of code reuse. Are you going to use your service elsewhere? Not just to feed your web tier?
We also reuse our services with jms bridges so we secure our service layer.
I think the Service is the better place to use it.
Despites some problems that #PreAuthorize could create on Controller and the Spring Security FAQ recommendation to put this kind of annotation on Service, I understand that the authorization for some action is more a business rule than a responsibility for the web tier.