What is DTO equivalent term for objects returned from DAL?

Question

I'm already using DTO's for data transfer over a network. Now I'm also introducing different DTO-like classes to the DAL. This is to avoid passing the application (business) objects across layers.

To avoid naming confusion, I would like to use another term than DTO but can't find a good one.

What is DTO equivalent term for objects returned from DAL?

Answer 1

"What's in a name? that which we call a rose by any other name would smell as sweet." - William Shakespeare

Also, what Martin Fowler says about POJO:

In the talk we were pointing out the many benefits of encoding business logic into regular java objects rather than using Entity Beans. We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely.

By the way, it does not matter that much. Looking at your concern to avoid confusion due to similar naming, you may choose from "DataModel", "Entity", "POCO".

Following are very loose considerations for different terms generally used:

Relational Model [Database Layer]:

• Database, tables and fields.

Persistence Model [Data Access Layer]:

• Model that (generally) belongs to ORMs or closely map with database.
• This is used for persistence needs.

Domain Model/Business Model [Business Logic/Services Layer]:

• Model that is exposed to BLL/Service Layer.

View Model [UI Layer]:

• Model that is exposed to View.

DTO:

• Holds only state and used to transfer data from one layer to other.
• Does not have any behaviour/logic except serialization.
• Preferably serializable.
• Designed against requesting layer; does not resemble with database.
• Does NOT have its own identity.

POCO:

• It is simply a regular object that has no references to any specific framework and does not follow their interfaces or restrictions.
• Persistence ignorant objects that can be used with any ORM.
• Holds data from database.
• Not necessarily serializable.
• Designed against database request.
• May have logic for validation or other that is tightly bound to POCO (like data encryption/uniqueness of column).
• Does NOT have persistence methods like Get, Save etc. POCO does not fill itself.
• MAY have its own identity.

Entity:

• It MUST have its own identity and can be uniquely identified.
• Object that can be loaded from and saved to a database using a DataContext.
• Cannot exist without its DataBaseContext.
• Tightly bound with specific ORM and implements its rules (default constructor, virutal properties to create runtime proxies etc.).
• Entities represent domain model and domain logic.

Model:

• Common term used to represent any object that holds data.
• All objects above, if we put any of it in MV* pattern, it becomes Model.

Refer following answers:

https://stackoverflow.com/a/37751345/5779732

https://stackoverflow.com/a/42801839/5779732