CODEWITHSUNDEEP
viewmodel
Adam
Adam

Reputation: 1299

ViewModel Class Design - Should it be on Server Side or Client Side?

In my application, I have a View and it needs data from multiple server side data models.

We have two options.

  1. Call a Single WebSevice once and get ViewModel class object from server side and bind it to the View.

  2. Call multiple WebServices and get different Server Side Model Classes and create a new View Model Class on the client side and bind it to the view.

What's the best approach out of these two options ? Please advise.

Upvotes: 0

Views: 1242

Answers (1)

Ben Cottrell
Ben Cottrell

Reputation: 6110

If in doubt, consider your UX.

One of the most frustrating things from a user's perspective is to be waiting for your app to respond after they've pressed something.

Every time your app issues a request to your server, users will experience a delay - each additional request increases the length of that delay. Most typical users have a very low tolerance for that sort of thing before they get irritated and decry your app as being "slow".

In the interest of minimising the time required for content to load, keep the number of calls between your client and your server API to an absolute minimum - In general, the fewer calls the better. This leans heavily toward the 'single request, single ViewModel' approach.

Also be mindful of the size of your ViewModel payload; don't just return a huge data-dump to your user when the majority of it will never be seen or used - not only does this waste bandwidth and make things slower, but it also implies the client is going to be doing additional unnecessary work.

This has benefits on your server too; with your server needing to fulfil fewer requests, you will have less work to do later on when scaling up your app to cope with more users.

Lastly, Consider the difference between a simple lightweight "dumb" client which is only responsible for presentation and user interactivity, versus a heavy-weight client application.

  • By making your Server responsible for generating a ViewModel and doing all the hard work, you can avoid business logic on your client; therefore maintaining clean separation between your Business and Application Layers.

  • On the other hand, if you require multiple server API calls, then it's likely you'll need a lot more complexity on your client to build your View Model, which risks blurring the line between your Application and your Business Layer.

If you eventually build multiple different client Applications which call the same server, you may find yourself needing to re-use that business logic between those applications; it's easier to re-use business logic which already exists on the server - especially if your client applications use different technologies (e.g. a Web Client and a Mobile App).

Upvotes: 1

Related Questions