Here is my Spring MVC file structure. I wanted to know which file belongs to which layer i.e. Presentation layer (I thinks .jsp files) , Business layer , Logic layer Edit: Database layer
So here which file belongs to which layer and any description about how that file add to layer will help me a lot.
When I learned Spring MVC from internet articles, they were using this short of packages. I appreciate if someone describe uniqueness of each package.
As you guessed correctly, the .jsp files are your Presentation Layer that handle how your data would look like.
Business Layer is where you write the business logic of your program. In your application, there does not seem to be any package that is doing this. The classes in this layer are usually Plain Old Java Objects (POJOs)
I am not sure what exactly you mean by Logic Layer because it seems to be same as Business layer.
There is another layer called the Data Access Layer which seems more evident in your application.
Package structure:
*.controller - Contains controller classes which handle URL mappings to specific views
*.dto - Data Transfer Object (DTO) are the objects that correspond to your DB tables and that help in implementing ORM
*.dao - Data Access Object (DAO) provide an interface to interact with your DB using the DTOs
*.doaImpl - Give concrete implementations of the DAOs
.jdbc - This package seems to be a utility class package used to create and manage JDBC connections
*.delegate - Are delegate packages which may perform one or more business functions using the delegation-pattern
Related
I am developing a web application using struts2 EJB3(Service/business layer) and Hibernate. I am using Wildfly 10 as a server. Struts is at presentation later, EJB3 at business layer along with simple java classes as Service layer and hibernate is used in persistence later.
Now in one of my action classes I have passed the modal object to the service layer(Simple java classes). Now when I created the EAR and tried to deploy it on the WIldfly. WIldfly refused to start. Then I realised that my ejb module is not able to find the classes of web module. So now I have two ways to resolve this problem:-
1) Either include my web classes in EJB jar:- I think it will completely kill the layered architecture and decoupling of presentation layer and service layer.
2) Or map the modal classes to some other modal classes present in service layer:- It will require to create redundant POJO classes in service layer as well.
Not really know what should I do in this case and if someboddy can suggest me with some better layering structure
There are serveral ways you can architect your models for each layer but at the end of the day, it depends on how much you wish to couple each layer with one another.
Obviously the most granular and cleanest solution is to allow each layer to have its own models and to map accordingly at each integration point.
Persistence models, e.g. your #Entity classes
Domain models, e.g. those your service tier takes as input and returns as output.
View models, e.g. those your presentation tier takes as input and returns as output.
The advantage of such a distinction is that it allows the models at each level to morph over time without a significant impact to the tiers above it. In other words, adding a new field or changing something with your persistence model doesn't necessarily mean your domain models must change, but just the mapping code between them.
Obviously there are a number of sources on the internet which advocate simply reusing your #Entity classes as the model at each tier and for simple applications, that's definitely acceptable. But in more complex, scalable solutions that eventually becomes a liability.
Sometimes it's acceptable to collapse (1) and (2) into a single model, the #Entity and then use special view models for rendering so at least your view code isn't impacted when you make model changes over-time, but I typically err on the side of using a different model for all three tiers in many cases for complex applications.
we have a platform composed of few applications.
We have to develop an API which must factorize all interaction to a database.
In this API, we will too have a version of the database in XML format.
The XML format will be used just by one application.
Our application are developped in a classic architectural : dao - service layer - presentation layer.
The DAO layer will be moved into API. No problem on that point.
In many application, the service layer is just a gateway between presentation & dao layer without specific business code.
So my questions are :
should we create the API with a Service layer for each dao ?
if yes, so keep a service layer in application which call service layer from API ?
should we create a service layer in API which manage the factory (database/XML), but that mean each application has to give an information to choose the dao to select (when just one application has this need) ?
or just create all dao in different packages for database & xml in API, keep factory in the application which has the need, and call dao (database) in all others ?
Need help ! :p
I'm lost...
FYI, we are in Java 1.6 with Spring 3.1.1. JDBC Template in DAO for moment.
We are looking informations about spring data jdbc to replace JDBC Template.
Any suggestion about that can be appreciated ^^
[ No Hibernate - JPA solution ]
Thank you.
[edit 1]
In other word, keep a service layer in application & in the API is a way for me to have an abstraction layer. If we have to modify the database structure, maybe we don't have to edit all applications if we can make some changes directly in the service layer of API too.
Imagine 3 possibilities :
service layer in API with factory to choose which dao to use (xml/database)
just dao in API
service layer in API for database & specific layer in API for XML
What solution do you choose ?
[edit 2]
Is it interesting to create an unique class to call the API ? like in a Facade design Pattern.
Use the Service Layer for what is meant to do: provide real world services, by using one ore more DAOs per service offered (and other stuff like managing transactions, sanitizing Strings and other things like that).
If you (together with a more experienced coworker) think you don't need this service layer, then do not put it into your architecture. But make sure to create a proof of concept of your architecture (this may contain the implementation of a somewhat complex functionality of the system or part of it) so you can evaluate it later to demonstrate if you really don't need such layer (or if you do).
My understanding is that you need to decouple and reuse the business layer from the presentation layer, having multiple client applications using the same business implementation.
In this case you need to implement the service layer in the API. Some advantages:
You don't need to repeat the service implementation for any client application handling the presentation.
You can easily decouple the database model design from the business. Design patterns (DTO, Facade) and cross cutting concerns may be easily introduced.
A well designed service layer will require a minimum amount of modifications, compared to DAOs holding DB implementation details.
In this API, we will too have a version of the database in XML format. The XML format will be used just by one application.
By providing this implementation via the API more client applications will be able to use it in the future, if needed.
Spring remoting is offering excellent tools for such a design (RMI, HTTP invoker etc)
I don't see any added value in proving an API for DAOs.
I'm designing a shopping cart web application in Java.
Many Java applications seem to adopt the same naming conventions which I would like to use.
For instance:
_ - entity which is persisted to database
___DAO - DAO which provides CRUD methods for persisting Item to database
___BO - I've only seen these used as a thin wrapper around DAOs. Is there any other point to these?
___Service - Used to expose API?
How do most designers split code between BO and Service?
If you are not using EJBs I think there is a little confusion. Your objects you are naming "entity" objects are the Business Objects. In a POJO based application BOs represent the domain. Take a look at this sample project: Spring's Pet Store.
The "domain" directory contains the BOs.
Note that there is a "service" and a "dao" directory, which obviously contain the respective services and DAOs.
I would use DAOs in service directly (no BOs) and point of service layer is to add caching, transactional stuff like thing also you could easily expose them as webservice if required
Consider the following example.
There is a server application that has three layers. The service layer that is exposed to the clients, the database layer that is used for persistence and the business layer that calculates something.
The application serves three different types of data. Users, Payments and Worktimes.
How should I package my application?
Package by layer:
foo.bar.service
UserService.class
PaymentsService.class
WorktimeService.class
foo.bar.persistence
UserPersistenceService.class
PaymentPersistenceService.class
WorktimePersistenceService.class
foo.bar.business
PaymentCalculator.class
Or package by type:
foo.bar.user
UserService.class
UserPersistenceService.class
foo.bar.payment
PaymentService.class
PaymentsPersistenceService.class
PaymentCalculator.class
foo.bar.worktime
WorktimeService.class
WorktimePersistenceService.class
I guess the first example could become confusing if the application grows and more and more logic is implemented. However, it appears to be easier to find the right place when the task is to "extend the persistent service layer to do something fancy".
The second example can be easier extended without flooding packages with millions of classes.
Is there any best practice to choose between them? Or do you guys have any other idea of a package structure.
As far as I am concerned I would package by layer AND type :
foo.bar.service.user.UserService
foo.bar.persistence.user.UserPersistence
And so on
For most of my projects I use maven and some multi modules :
Domain Model (Model Objects)
Persistence
Service
Applications
With this way, you could get different jars (or not if you have got only a simple project) and it is easier to retrieve the good place to extend/modify the existing sources.
What is more important for your application?
Do you deploy the layers/types to different machines (or might want to do so in the future)?
Do different people work on different layers/types?
If so use layers/types to seperate packages.
If your application is a little larger, you probably want to use both, resulting in packages like
foo.bar.<layer>.<type>
or
foo.bar.<type>.<layer>
Usually there is a model package in which you put the types (Users, Payments and Worktimes in your example).
Next to the model package there are layer packages like presentation and service (I normally nest data access layers within the service package to encourage these layers to only be used from service implementations but that's up to you).
If the project is a bit bigger I split out the service layer into a separate module. If it is bigger still (or the domain model is large and complex) I also move the model package into a separate module, resulting in a three-module project: model, service and presentation.
If there are also multiple presentation channels (e.g. web application, REST service and dekstop client app) these can also be split out into separate modules.
I am new to Spring and hibernate.
I am trying to learn the best practices and design methodoligies in j2ee apps.
I have a managed to create a basic spring mvc web app. now lookin for that
- how should i map my service beans to dao beans or should just use dao beans only.
- Is there any need to make DAO classes singleton
- If i use same dao bean for the jsp, then e.g. onSubmit if I have to enter data on multiple tables (dao beans) then how would I do that.
1 service bean to more than 1 dao beans??
and any refrence material on designing good web app using spring hibernate would appreciated ;)
thanks
You must use service bean. service logic should be there only.
DAO should only for DB related operation.
Now you can inject multiple DAO in your service bean.
FWIW - I just went through a similar learning process on Spring. The good news is, there are a lot of examples out on google; the bad news is, there are not a lot of "complete" examples that are good for rookies (also if you are going to target v3 Spring, there is a lot of pre-v3 stuff out there that can be confusing based on the new baseline). What worked for me was the following: started with the sample applications on the SpringSource site (http://www.springsource.org/documentation). Between their handful of examples, there are just about all the pieces you will need, at least in minimal form. When I found something in those examples that I needed, I googled based on similar terms (some of the # annotations etc) to find more complete information/better examples on that given topic. Many of those searches led me back to this site, which is why I started frequenting here - lots of good questions already answered. I guess this isn't an overly insightful answer, but this process got me up and working through the basics in a fairly quick amount of time.
DAO layer and service layer are different entities:
DAO is responsible for getting and putting single objects from\to DB. For example, get User(id, name, lastname) from DB.
Service layer is responsible for your business logic. It can use several DAO objects for making one action. For example, send message from one user to another and save it in sent folder of first user and in inbox of recipient.
A service is about presenting a facade to the user that exposes business functions that the user can take. Basically, if you have a set of low-level use cases, the methods on the service would line up with individual user actions. Services are transactional, generally if the user does something we want all the consequences of that action to be committed together. The separation between controller and service means we have one place to put webapp-specific functionality, like getting request parameters, doing validation, and choosing where to forward or redirect to, and a separate place to put the business logic, stuff that doesn't depend on webapp apis and is about what objects get updated with what values and get persisted using which data access objects.
I see a lot of cases where people seem to think they need one service for each dao. I think their assumption is that because Data Access Objects and Controllers and Models are fairly mechanical about how they're defined, services must be the same way, and they construct them with no regard for the use cases that are being implemented. What happens is, in addition to having a lot of useless service boilerplate code, all the business logic ends up in the controller jumbled up with the web-specific code, and the controllers become big and unmanageable. If your application is very simple you can get by with this for a while, but it is disorganized, it's hard to test, and it's generally a bad idea. Separation of concerns, keeping infrastructure code in one place and business code in another, is what we should be aiming for, and using services properly is very helpful in getting there.