I was watching "storefront starter kit", its using repository pattern with service layer. In the video, he didnt really explain why he's using service layer. Seems like those are just extra.
what are pros and cons using service layer?
Repository is your Data Layer ... it's responsibility is to fetch and save data.
The Service Layer is your Business Layer ... it's responsibility is to hold all your business logic.
For most asp.net mvc apps it is perfectly reasonable and preferable for your controllers to directly address the repository (via an interface). I would only add a service layer when you need to, for example when other apps are interfacing with your application. In my opinion you should avoid unnecessary abstraction layers.
Related
In a three-layered architecture, where is the DAO pattern located? Is it in the business logic layer or in the data layer?
I'm not sure that thinking in terms of layering is useful anymore.
We used to have 2-tier client-server, with all the logic in the client and a database running on a server.
We evolved to 3-tier, usually associated with MVC model-view-controller. There wasn't a mention of data access objects in the original Smalltalk MVC pattern.
Now I think view and controller generally go together, splitting rendering of the user interface between client and server. Controllers have business logic and interact with many web and data access services. Data access objects would be used by controllers to deal with data sources. Call that whatever layer you wish.
I don't think of microservices as a layer. Perhaps the usefulness of the concept has diminished.
Apologies if this has been somehow already answered somewhere - I can't seem to find an appropriate response to my question. Here goes ...
I am currently working on an app accessible via REST. My current teck stack is as follows:
The presentation layer - exposing the functionality in REST
The service layer - taking care of all the business logic, and
The persistence layer - taking care of all DAOs and database-related affairs.
All of this (including Shiro) is autowored using Spring's IoC.
Shiro is currently wired in the presentation layer, making sure all of the calls are protected. The questions I have are: is this the right approach? Does it make sense to apply it to the service layer and, even more so, to the persistence layer?
Many thanks.
The great thing about shiro, is that it can be used at any level. The only thing that really is needed is the idea of a logged in user. In a web framework, this would normally use standard the standard servlet HttpSession to bind it, but that is not necessary.
In our application, we use it at the presentation level to check whether the user has the appropriate rights to view front end pages.
At the business logic level, we call stuff like SecurityUtils.getSubject().isPermitted("somepermissionstring") in custom logic to make sure the user can't call a method when a button is accidentally made visible for that user.
In the frontend code we use the same idea as the business logic.
It works like a charm for us.
So to answer your questions (IMHO):
is this the right approach? -> Yes
Does it make sense to apply it to the service layer -> Yes, if you need very strict security checks!
and, even more so, to the persistence layer? -> Maybe. You have to ask yourself if the security on the service layer might not be could enough, for example if you expose the persistence layer to some code that doesn't go through the service layer. We do not secure the persistence layer as we only access it via our service layer.
Currently i'm part of a project (spring with JPA) that has the following layering:
service layer (checks for authorization and delegates actions to
the manager layer)
manager layer - does lots of buisiness logic
and then calls: entityManager.save(object)
As you can see there is no DAO layer in this project and as a DAO layer fanatic i'm starting to fall in love with this setup instead.
what are the pros \ cons of this setup?
Should we bother with dao?
Separation of concerns is the word that you should think before falling in love with this approach. In general practice business logic and dao logic should be kept separate as in case if in future you decide to change your database you need not go through every class searching for change the way to access new database but in DAO layer approach you need to change only your DAO layer as business layer remains intact.
Folks,
Apologies if this has been covered in another thread, but I have searched ddd and mvc articles and have not found a straightforward answer.
I am hoping to apply a DDD approach to the architecture of my MVC projects. Please correct me where I am wrong.
All MVC controller actions that involve hitting the domain model will initially hit
and application service layer.
The application service layer here acts as a facade between presentation and the domain.
Any requests from the application service later that clearly involve discrete domain aggregates will perform fetch or modify operations on aggregate roots using repositories. Each aggregate root will have its own repository.
so the application service layer must be injected with any/all repositories required by the domain.
Where an operation may involve multiple aggregates or requires logic that does not fit neatly into one aggregate, the application service will call a domain service to carry out operations across aggregates.
This does not seem right to me.
My confusion is that from a DDD perspective Im not sure whether for example aggregate roots should perform their own persistance i.e. the aggregate gets injected with a repository and then persists/fetches itself or whether as above the application service layer uses repositories to act on or fetch aggregates?
Also if the application service layer is injected with all repositories, does the domain service that the application service layer calls also need repositories injected?
Im keeping CQRS out of this at this point. I want to get the layering and the relationship between services and aggregates sorted out first.
Thanks for any advice.
All MVC controller actions that involve hitting the domain model will
initially hit and application service layer. The application service layer here acts as a facade between presentation and the domain.
There's debate over that but I would consider carefully whether that additional layer is needed or not. It adds a lot of boilerplate code and degrades maintainability - as someone pointed out recently, when you separate things that change for the same reasons (ie your service methods and the corresponding domain methods), you have to make changes in many different places in the system.
On the other hand, you could need that service layer to map your domain objects to DTOs but there again, it could be done directly in the Controller and nothing forces you to use DTOs in the presentation layer.
My confusion is that from a DDD perspective Im not sure whether for
example aggregate roots should perform their own persistance i.e. the
aggregate gets injected with a repository and then persists/fetches
itself or whether as above the application service layer uses
repositories to act on or fetch aggregates?
It's usually considered bad practice to have aggregate roots manage their own persistence because it breaks persistence ignorance and violates the Single Responsibility Principle. If you do that, your aggregate root class now has 2 reasons to change, 2 reasons to break the code, it is less maintainable, etc.
You should instead delegate the responsibility of saving the aggregate root in its repository to an object that will be aware of the application execution context (for instance, a Controller or an object in the Application layer).
Also if the application service layer is injected with all
repositories, does the domain service that the application service
layer calls also need repositories injected?
Yes, I think it pretty much makes sense especially if the domain service heavily relies on the repository.
Could anyone please give some examples of possible service. I am going through the book, but cannot understand what can the service do? It provides processed data for modelAndView to controller, but what it looks like is it java bean connecting and retrieving results from database, what can it be?
A service component is where all your DAOs come together and have the business logic. You can think of it this way.
DAO - should only load data from db. Nothing more.
Services - can use daos to load multiple objects and do some kind of business logic
controllers - use services to load objects. They should have nothing more than simple logic because complicated logics should really belong in the service. Reason for this is in the future when you want to reuse this logic, you can do so if its a in service but not if its in the controller.
Example:
BookDAO - Loads the book
BookService - loads the books for a person that is logged in
Finally, I'd like to quote the grails doc for a clean concise quote.
As well as the Web layer, Grails
defines the notion of a service layer.
The Grails team discourages the
embedding of core application logic
inside controllers, as it does not
promote re-use and a clean separation
of concerns.
An example of an Service could be an Email Service in an Business Application (not in an Email-Client). This Service offer other Components the functionality (service) to send emails to notify users about stuff.