What is the difference between DAL, DTO and DAO in a 3 tier architecture style including with MVC

Question

Recently I was learning about ORM (Object Relational Mapping) and the 3 tier architecture style (presentation,business and data persistence). If I understand correctly, I can separate the data persistence layer into DTO and DAO layer.

I would like to understand, how the following parts works together in a data persistence layer.

• DAL (Data Access Layer)
• DTO (Data Transfer Object)
• DAO (Data Access Object)

In a top of that I learnt that

In larger applications MVC is the presentation tier only of an N-tier architecture.

I got really confused, how it can be even possible for example in a 3 tier architecture style where the MVC is the just a presentation tier, and the DTO, DAO, DAL is just a part of data persistence tier. I'm totally lost.

I'd be glad if someone tell me the truth about how does it works together.

Please don't close this question because the many different expressions, I saw it everywhere these things are related to each other basically in big applications and I can't imagine how does it works.

I appreciate any answer!

Tafoya

Answer 1

Lets start with purpose of each: -

DTO

Data Transfer Objects. These are generally used to transfer data from controller to client (JS). Term is also used for POCOs/POJOs by few which actually holds the data retrieved from Database.

DAO

Data Access Object is one of the design patterns used to implement DAL. This builds and executes queries on database and maps the result to POCO/POJO using various other patterns including 'Query Object', 'Data Mapper' etc. DAO layer could be further extended using 'Repository' pattern.

DAL

Data Access Layer abstracts your database activities using DAO/Repository/POCO etc. ORMs help you to build your DAL but it could be implemented without using them also.

MVC

Model View Control is a pattern which is used to separate view (presentation) from business logic. For MVC, it does not matter if DAL is implemented or not. If DAL is not implemented, database logic simply go into your model which is not a good approach.

In larger applications MVC is the presentation tier only of an N-tier architecture.

Models consume most of your business logic as stated above. In N-tier application, if business logic is entirely separated for the purpose of re-usability across applications/platforms, then Models in MVC are called anemic models. If BI need not to be re-used at that scale in your application, you can use Model to hold it. No confusion, right?

I'd be glad if someone tell me the truth about how does it works together.

All MV* patterns define the idea/concept only; they do not define implementation. MV* patterns mainly focus on separating view from BI. Just concentrate on this.

Refer this answer for details about different objects holding data.

Hyperbola

DAL = persistence layer? – Noelianoell

@YoushaAleayoub: Data Access Layer (DAL) handles data access as well as persistence. So.....yes: DAL = Persistence Layer. If you further decide to split it in two say 1) Read Only DAL (READ operations only) and 2) Write Only DAL (CREATE, UPDATE, DELETE operations only), like something in CQRS, then not sure what proper naming should be. May be Query Layer and Command Layer in that case. But personally, I use DAL in general. – Hyperbola

Answer 2

You might wanna first distinguish between the MVC pattern and the 3-tier architecture. To sum up:

3-tier architecture:

• data: persisted data;
• service: logical part of the application;
• presentation: hmi, webservice...

Now, for the above 3-tier architecture, the MVC pattern takes place in the presentation tier of it (for a webapp):

• data: ...;
• service: ...;
• presentation:
  • controller: intercepts the HTTP request and returns the HTTP response;
  • model: stores data to be displayed/treated;
  • view: organises output/display.

Life Cycle of a typical HTTP request:

1. The user sends the HTTP request;
2. The controller intercepts it;
3. The controller calls the appropriate service;
4. The service calls the appropriate dao, which returns some persisted data (for example);
5. The service treats the data, and returns data to the controller;
6. The controller stores the data in the appropriate model and calls the appropriate view;
7. The view get instantiated with the model's data, and get returned as the HTTP response.

Ornithomancy