0

So, somebody at work who is twice as experienced than I am, told us that we must not create ViewModel classes within Web API. (We are using Angular for UI)

In his opinion ViewModel is ASP.NET MVC approach. And we must come out of it when using Web API.

Here is my argument for using ViewModel in WebAPIs:

Database Tables

Employee

name | phone | categoryId |...Col15

Category

categoryId | Description

C# Class

Class Employee
{
 public string name {get;set;}
 public phone {get;set;}
 public categoryId {get;set;}
 //...till col15
}

If your UI page shows only :

 name | phone | categoryId | CategoryDescription

Wouldn't it make sense to create a ViewModel class in API that has only these 4 properties as opposed to all 15 properties? The JSON that will be returned by this class will only have 4 properties instead of 15 properties where 11 of them contain null value.

If there is a list of say 100 Employees it would mean 1100 empty json properties that will be sent to the UI if we use original Employee class instead of a ViewModel class.

Also, if we stick to our original Employee class we might have to do one of the following:

  1. CategoryDescription must be added to original Employee class
  2. Make a second API call from UI to get the description.
  • 4
    It's fine and good, just don't call it view models. Call them resource models or something like that, and everyone will be happy. – JacquesB Oct 11 at 9:27
  • 1
    Or DTOs. – John Wu Oct 15 at 8:50
1

Yes it is bad practice.

Essentially you are moving logic from your javascript client application to the server side.

This works well when you are making page requests with little or no client side logic, but not when you have a single page app where all of the presentation logic at least is supposed to be client side to take advantage of the various benefits that can bring.

So in your first example, if you create the EmployeeViewModel with cut down fields, but then later need one of those fields on the front end, you now have to edit both front and back end.

in your second example where you enrich the employee with the category description, your client is quite capable of requesting the information separately, holding it in memory and joining it to employees, using it in drop downs etc etc

In each case adding a view model to the server reduces the flexibility and available options in your client side code

  • I agree that introducing ViewModels would mean making changes to both client and server end but wouldn't ViewModels mean better performance? We could save multiple calls to the server. – SamuraiJack Oct 11 at 17:42
  • @SamuraiJack: I would measure a performance problem first before using view models in a web API. In fact, I would verify first that the performance of not using view models is, in fact, unacceptable to end users. Just defaulting to view models in a web API might be premature optimization. – Greg Burghardt Oct 11 at 18:52
  • If the project is finished, then you could go through and optimise to reduce the number of calls. But this comes at the cost of reducing your flexibility going forward. Also reducing the number of calls does not necessarily improve performance overall – Ewan Oct 14 at 8:03
  • @SamuraiJack: to build on what Ewan said in his last comment, you really need to know where the performance bottleneck exists first. You can spend a lot of time and money refactoring your API responses to only realize you need to paginate data, rather than fiddle with the data structure, because the client cannot handle that much data at once. Raw HTTP responses should be at least compressed with GZIP compression (or something similar). That is a much more efficient means of reducing network time. – Greg Burghardt 2 hours ago
0

In principle, frontend frameworks such as Angular are best used against a REST API, which implies that you don't have viewmodels and simply expose your resources as they are.

However, from the sound of it, you're not using a REST API but rather an API tailored to the needs of the frontend application. I say this because you mention that the API specifically omits 11 out of 15 properties because it knows that the frontend won't need them for this particular case.

If that is the case, then your API is inherently aware of your frontend application views, and you are effectively working with viewmodels. It seems like your colleague is simply suggesting to not make an explicit viewmodel and instead is trying to reuse existing DTOs but with properties that are intentionally kept empty, which is not good practice.

So, to summarize, the "no viewmodels" stance works if you have a REST API. If you have an API which handles custom requests and automatically redacts data because it knows what the frontend will/won't display, then the "no viewmodels" stance is contradictory to how the API is being developed.


Additionally:

In his opinion ViewModel is ASP.NET MVC approach.

MVC stands for Model-View-Controller. MVC has no viewmodels. MVVM (Model-View-ViewModel) however does have viewmodels.

I'm not sure whether this conflation is on your side or on your colleague's side, but it's nigh impossible to productively discuss the use of viewmodels (or lack thereof) if either party can't distinguish MVC and MVVM.
At the very least, you'd be using the wrong name (viewmodel vs model), which makes it really hard for other people to provide accurate feedback based on your explanation.

  • I'm on the fence about this answer. The "view model" concept is something only the server application cares about. You don't necessarily want to expose the entire resource in your REST API due to security concerns, and especially since you don't want badly/maliciously crafted requests to result in business rule violations. A REST API is not simply CRUD operations on a table in the database. It still must go through business rules and constraints, but "act" like a resource to the outside world. – Greg Burghardt Oct 9 at 17:28
  • @GregBurghardt: I didn't mean to imply that you must expose the whole entity. What I meant is that in a pure REST API, the resource is exposed the way it is intended to be exposed, regardless of which (partial) view the information is going to be being displayed in. Effectively, the backend doesn't know what specific (partial) view the data is going to be used in. But I guess this is open to subjectivity, one man's resource with redacted properties is another man's (view)model I suppose. In the end it's all about DTOs. – Flater Oct 9 at 17:30
  • I understand that if we are developing a generic REST API for 20 clients whose needs might defer then it would make sense to expose DTOs instead of creating methods and ViewModels to suit each of the 20 clients. But if we are developing an API for just one or two clients. we would be better off creating ViewModels. Am I correct? – SamuraiJack Oct 9 at 17:39
  • 2
    @SamuraiJack: Not particularly. It's a matter of approach. A REST API can make sense for a low number of consumers too. A REST API is generally more loosely coupled to its frontend. When the frontend and backend devs are in different teams, it requires less coordination between the two. It also allows for simpler changes since the BE doesn't need to be changed when the FE adds/removes a display field. But a more tightly coupled API can save more on calls/performance when written well. Either can work, either has its advantages. – Flater Oct 9 at 19:35
0

According to me, if you are using a repository pattern in your Web API project then in that case, it is good practice to use view model for the direct interaction with the database from front end side. In other cases, you can do operations without using view models.

0

What you are doing is fine. You should expose only the data which is necessary for the clients.

Just don't call it "view models" since this term have a specific meaning in the context of user interfaces and will create confusion when used outside of this context. Call it "Data Transfer Objects" and everyone will be happy.

It is not a good idea to expose entities directly through an API. This creates a tight coupling which means any minor change in the business logic will cause breaking changes in the API (and vice versa). You want to avoid that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.