What is the difference between an MVC Model object, a domain object and a DTO

Question

What is the difference between a MVC Model object, a domain object and a DTO?

My understanding is:

MVC Model object:

Models the data to be displayed by a corresponding view. It may not map directly to a domain object, i.e. may include data from one or more domain objects.

1. Client side
2. May contain business logic. Eg. validations, calculated properties, etc
3. No persistence related methods

Domain object:

An object that models real-world object in the problem domain like Reservation, Customer, Order, etc. Used to persist data.

1. Server side
2. No business logic

DTO (Data Transfer Object):

An object used to transfer data between layers when the layers are in separate processes, e.g. from a DB to a client app. Allows a single transaction across the wire rather than multiple calls when fetching data corresponding to multiple domain objects. A DTO contains just data and accessor methods and there is no logic present. The data is for a particular DB transaction, so it may or may not directly map to a domain object as it may include data from one or more domain objects.

1. Used on both server and client sides as it is passed between layers
2. No business logic
3. No persistence related methods

So, the questions:

1. Is above understanding correct? Am I missing some key points?

2. Are there any reasons not to use Domain objects as the MVC Model assuming that the Model objects do not require extra business logic?

3. Are there any reasons not to use DTOs as the MVC Model assuming that the Model objects do not require extra business logic?

Solution 1

Domain and model objects are essentially the same, and may contain business logic. Depending on implementation, domain and DTO objects may be equivalent if you remove business logic from the model into a service class.

Often a key variant of the DTO is the View Model, which is used purely to transfer data between the domain model and the view, although often a View Model may contain logic, although this should be purely UI logic.

Solution 2

The Domain and DTO can also be your "model" objects - you can have a view to render the details of the "Customer" domain object.

A domain object can have business logic to enforce the properties of the domain entity. validation is one such case. The domain object by itself does not contain persistence related methods, but it can have meta-data (like annotations) to support persistence

the POJO programming model makes it possible to use the same object as your domain, DTO and model objects - essentially, you will not be implemented any extraneous interfaces that will only apply to one layer but does not apply to others.

Solution 3

A DTO = is an object that carries data between processes.

But the most interesting part is that, it does not have any behavior except for storage and retrieval of its own data!!!

Sticking with the MVC methodology...

Domain = subject of your entire application.

Model = contains the (programming languages objects : EX: C# objects) to make up the universe of your application.

They can obvioussly have behaviour and properties(see difference with DTO).

Often an application (a light one) can have one model - case in which your model is exactly your domain. Another model can be, a totaly different object type, that is processing another one. Both of them, in this case are part of your domain, and are named "domain models - objects".

Hopefully this answer is exhaustive and makes it all clear for you !

Solution 4

My understing (in a big short) is as follows:

(MVC) Model object:

• represent some things in a some usage context eg. PersonEditModel, PersonViewModel or just PersonModel
• has no business logic
• can be subject of some valdation logic etc.
• used to provide data from one application layer to another eg. MVC Controller <-> MVC View

Domain object:

• represents some business object (real world object in the problem domain)
• has business logic
• do not allow invalid object state, has methods to properly change object's state
• used to encapsulate business logic related to it
• have not to be used to persist data (or even should not)

DTO (Data Transfer Object):

• similar to Model object but should have flat structure
• only simple type properties/fields (strings, numbers, datetimes, booleans)
• used to transfer data cross application boundaries eg. between web server and web browser

Solution 5

Any definition for most of the objects is various based on place of using of objects:

Model: is a general definition for using object in client or server.

1. Model View : is a object using in client most of the time.
2. Domain Object : is a object using in server and transfering data to the database.
3. Data Transfer Object(DTO) : is a object that transfer data from one object to another object, specially in getting data in API Call(for example: in api GET Method call for getting data you must not to give database models to client, for this purpose you use dto).

Notice: the definitions are true most of the time but in some situations arent't practical.

View more solutions

Comments

[Timothy Mowlem]

Yes this is what I am doing. Indeed in nearly every case I have never had a need to use anything other than the Domain object. DTO would be for a complex query with multiple data items spanning domain objects.

[Timothy Mowlem]

And a separate MVC Model class is only really necessary if there is significant business logic/processing associated with the model data to be displayed?

[kartheek]

yes, that will be one reason to have a proper dedicated model as opposed to using a domain object. Your domain object might be storing the date only UTC and that's enough for all your biz logic also. But on the UI, lets say you will have to display it in the user account's timezone. A model will be useful to for doing this UI specific computations.

[Timothy Mowlem]

Thank you to both the responders. It seems more clear to me now. Domain objects can have business logic like validation, logic related directly to the data.

[Timothy Mowlem]

A separate MVC Model object is only necessary to encapsulate logic related to the displaying the data in the view. If there isn't any then it is easier to use the domain object as the MVC Model object.

[Gaurav]

flawless answer !

[Andres Camilo Sierra Hormiga]

You'll may want to have model classes if you're going to test some UI behaviors. You can pick, shift and fix some view model in complex applications.