Timeline for Is creating ViewModels in Web API a bad practice?
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 21, 2024 at 23:08 | comment | added | Flater | @nicholas: To use an example, a viewmodel (MVVM) would track if you have opened/collapsed an accordion in the UI. A model (MVC) doesn't care about those things; it only cares about what data is being passed from the controller to the view. The state of the view is managed in the view, from the perspective of MVC, it is not contained in the model. | |
| Jan 21, 2024 at 23:06 | comment | added | Flater | @nicholas: I agree that this is a bit of a semantical minefield that MS could've avoided better, but the "model" from MVC is indeed a model that is passed to the view (which in standard English can be expressed as "view model"), but it is not a viewmodel, which is a more specific technical term relating to a data object that represents the state of the view, not just of the data that you want the view to render (= model in MVC). It's a horrible naming, but "viewmodel" is different from "view model". MVC has the latter, not the former. | |
| Nov 4, 2021 at 14:50 | comment | added | nicholas | @Flater the statement that MVC has no View Models is not correct. Although Microsoft could have done better with naming, as far back as MVC3, MS documentation referred to the classes passed into the views as "view models". In more modern times, the MS ASP.NET Core Architecture Guide clearly shows MVC and View Models are not mutually exclusive concepts. ViewModel refers to any class consumed by the UI, often a projection of a corresponding "domain model" class. | |
| Oct 9, 2019 at 19:35 | comment | added | Flater | @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. | |
| Oct 9, 2019 at 17:39 | comment | added | SamuraiJack | 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? | |
| Oct 9, 2019 at 17:30 | comment | added | Flater | @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. | |
| Oct 9, 2019 at 17:28 | comment | added | Greg Burghardt | 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. | |
| Oct 9, 2019 at 17:23 | history | answered | Flater | CC BY-SA 4.0 |