Layered/Tiered Architecture - Segregation of code

Question

From last few months I have been working on an enterprise application with spring-mvc . I have heard about 3-layer architecture with these layers/tiers - UI, Business Logic and DAO. This architecture is known to me. But while working on some spring-mvc enterprise projects I have found some layers like this (based on the code flow) -

 Controller  
    |
    v  
 Service  
    |  
    v
 Manager  
    |  
    v
   Dao  

I found the above layerd structure a bit confusing compared with 3-layer architecture. Because I have found some business logic written in both service and manager layer. The mixing up might be caused by lack of care or there wouldn't be other options rather doing this. But like 3-layer architecture there may be some reason behind each layer. Can someone explain why these layer for?

Probably this is not a good question based on stackoverflow 's specification. But this would be helpful enough as as a suggestions/tips to follow for new developer like me.
Thanks.

Answer 1

That is an MVC (Model-View-Controller) Architecture rather then the older (but still widely used) Data - Business Logic -- UI model. They are simply different architectural models and while they can and are compared and contrasted they most definitely do not map to each other one for one. If you find yourself working on a project that utilizes MVC I highly recommend that you find a book on MVC (or even specifically on Spring-MVC) and do some studying.

Answer 2

I have implemented a design very similar to the one you describe. My reasoning behind it was the "Manager" layer would help abstract any specific data access code away from the service layer.

So a service that looked like this (pseudo-code):

function getCustomer(id) {
    sql = "select * from customer where id = @id";
    return db->execute(sql, id);
}

ended up looking like this:

function getCustomer(id) {
   return dbo->getCustomerById(id);
}

This extra layer did a few things for my project. It centralized all data access, allowing me to use the manager classes in other projects. It also gave me the option (heaven forbid) to more easily switch between different data storage strategies (structured sql -> nosql) without having to change any of my service layer code.