Why do we need services? If we are going to implement web services.

[tczhaodachuan]

I think each entity, DAO is enough, the way to implement this project looks not simple and insufficient. We only need another layer called web service to map controller to DAO, that's it. The only challenge we have is how to solve the dependency between tables to map to DAOs, we can choose either factory design pattern or singleton pattern. We don't need services layer if the method offered is enough from DAO.

[typischmann]

It is a architecture problem. DAO is the API for persistence. It means that it isonly responsible for data accessing. The business logic must be separated from the persistence, e. g. in the database sketch, every product has its own price, but order has no definition of total price. If user want to see the total price of a order (the sum of the prices for the products under this order), this computation should not happen neither in database nor in the persistence (DAO), because it is a real business logic computation and not a accessing to data and should(can) not be persisted in data base. Therefore, we must encapsulate it into a separate module.

Some history about enterprise development:

In the beginning there was no explicit concepts about persistence and architecture(long long ago) database <--> data structure +business logic <--> representation (UI)

A classical three leverage architecture in the old old time(more than 10 years ago?): database <--> persistence <--> business logic <--> representation

But there was a huge problem for the tight coupling between business logic and representation, until web services(esp. SOAP) was introduced (8 years ago). Hence, a new three leverage architecture was introduced: database <--> persistence <--> business logic <--> web services <--> representation

Today, this general architecture is mostly accepted and stable. The further development is focusing on architecture implementation (such as distributed, centralized or cloud basing, etc...) or technology improvement (such as noSql database, new MVC framework, e. g. angularjs)

[tczhaodachuan]

What you said is a good point. But this can be solved by 3 tier architecture http://en.m.wikipedia.org/wiki/Multitier_architecture What are the other benefits we add one more layer?

[typischmann]

actually in this article from your links, we could map our architecture to the three tier as followings: data tier (one server): database logic tier (one server): persistence <--> business logic <--> web services (What I was saying is we can put logic into web services, why we have to separate logic? What logic can do, DAO is able to do it. DAO -> logic ->web services, logic doesn't offer benefits for our data structure.) representation tier (one server/clients): representation

What I have depicted is the logical architecture, it is a more detailed design. The tree tier architecture you have posted is coming from the point of view from servers, it is a general model. There is no difference between two ideas, only from different view points.

[typischmann]

additional comments:

In some huge projects, especially for these projects with ejb, jndi technology, the persistence and business logic could be actually deployed on different servers standalone. In these multi-tiers projects one layer can be deployed on one server or one cluster of servers to make the load balance on machine.

One Server is not equal to one machine. Server is also a logical/software concept. (I am not sure if the definition is right, but you know what i mean)

[typischmann]

I wrote a simple case. Perhaps, it can explain some your questions about JPA

There are a person table and a address table. Every person has its own address. If we want to make a function that return a person's address object by person id.

With JPA + Spring

Case 1: If Person Object has only address id

@Autowired private PersonDao personDao; --> Memory Management overhead

@Autowired private AddressDao addressDao; --> Memory Management overhead

public Address getAddressByPersonId(Integer personId){ //Database+Communication+Resource Overhead
Person person = personDao.getById(personId);

//Database+Communication+Resource Overhead
Address address = addressDao.getById(person.getAddressId()); return address; }

Case 2: If Person Object has address entity object

@Autowired private PersonDao personDao; --> Memory Management overhead

public Address getAddressByPersonId(Integer personId){ //Database+Communication+Resource Overhead
Person person = personDao.getById(personId); return person.getAdress(); }

Now you can see that whatever coding or the performance complexity as well as resource efficiency, the case 2 has a obviously advantage

[tczhaodachuan]

I see, if this is the case, we should embed entities.

[typischmann]

http://blog.xebia.com/2009/05/11/jpa-implementation-patterns-service-facades-and-data-transfers-objects/

A good and deeply investigated article for multi-tier architecture including webservice and service. I recommend you to read it that it has many good points that we could take into considerations for our webservice.

[typischmann]

I think the discussion is already finished. we have reached a agreement about the future architecture and development. Some articles and investigations during this discussion are very useful and valueble!