What is the difference between DAL, DTO and DAO in

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!

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.