Can we use only DTO instead of ViewModel? [closed]

Question

We currently use DTO for Web API request and response

and use ViewModel to pass data to the View in MVC

Currently, we have:

1. DTO as a separate project
2. ViewModel is inside the UI project (another folder along with Controllers)

Only difference I see in our case is that DTO has to be passed over the wire and sent as JSON while ViewModel has to be passed inside the view to be render as HTML.

Should we mantain separate transfer objects for MVC applications and our App/other clients OR do both of these jobs through DTOs only i.e. passing DTO inside the View instead of ViewModel? What could be possible downside of it?

I read many responses here but there's no example and convincing reason to keep separate ViewModel and DTO in our case.

Answer 1

Keep them separate

Bob did that once. He had a web site that displayed a user's profile, with things like their name and phone number. And he also had an API call that allowed a client to retrieve the same profile with the same information. So he used the same class for the web site's ViewModel and the API's DTO.

All was well at first. In fact, the business grew so well that Bob was able to sell his stock options and retire. The software engineering department became largely outsourced and people didn't really talk to each other.

A year later, the product owner, responding to customer requests, added a requirement that the profile page display not just the user's first and last name but also the user name and email address. A developer picked up the task and implemented it by adding a Login member to the ViewModel and populating it using AutoMapper. He believed the ViewModel was server side code and didn't think about it too much.

The company pushed a production live and the user name feature is a success. There was just one problem. All the API clients were now receiving JSON that contained the user's login, email address, and everything else, including their hashed password.

Don't be Bob.

Answer 2

I can share my experience with this pattern as I have implemented it in a project. Consider the project as a simple CRUD application with distributed architecture and is divided into three solutions:

• Project.Web (MVC Application)
• Project.DTO (Plain C# classes)
• Project.API (Web API Application)

Project.Web contains UI logic of the application and depends upon Project.API for all the CRUD operations, since database related operations are performed in Project.API.

Now comes Project.DTO, it contains plain C# classes and is used to transfer data to and fro.

Project.Web <---> Project.API

To make it more distributed, I have created Project.DTO as a Nuget Package and hosted it in Artifactory( you can use Nuget or any other repository) and consuming it using Nuget Package Manager. The main advantage with this approach is DTO classes are always versioned and easy to consume.

Coming to your question about keeping View Model and DTO separate, I can see the following points in favor of it:

• Data transfer from API to Web and vice versa: It can be large and complex. Let say my application wants to create a client and add all its detail into the database such as Client Address, Client Communication, Client History etc. In Project.Web, we can have other details such as Session Related Data, UI specific data that need not require to be transfer from Web to API. Hence, creating a separate DTO makes sense that transfer only such data which is common to Web and API and is independent of projects.
• Incoming Requests to API or Web: Let say, I have created a mobile application and is ready to consume Project.API. If, I have not created separate View Model and DTOs, I should be exposing my ViewModels to the client (mobile application) which is not advisable as it may contain sensitive fields that should be kept private.
• Separation of Concerns: Keep your DTOs only to pass data and for any other process witihin the application, use ViewModels. Maintain the separation of concerns principle.

These are few points I can think of related to your question.