8

I have just been thinking about the concept of view model object we create in asp.net MVC. Our purpose is to instantiate it and pass it from controller to view and view read it and display the data.

Those view model are usually instantiated through constructor. We won't need to initialize the members, we may not need to redefine/override parameterless constructor and we don't need inheritance feature there.

So, why don't we use struct type for our view model instead of class. It will enhance the performance.

tereško
  • 58,060
  • 25
  • 98
  • 150
Jonas T
  • 2,989
  • 4
  • 32
  • 43

2 Answers2

18

You take "it will enhance the performance" as a given, but are you really sure about this? Structs perform better than classes in very specific circumstances. I'm generalizing for simplicity, but the scenarios chiefly are:

  • They're immutable.
  • They're small, e.g. usually no more than 3 - 4 fields.
  • You're generating tons (often millions or more) of them over an extremely short time span.
  • You're working with them in tight loops.
  • The code paths that they travel through are optimized for those specific structs and do not perform boxing / unboxing operations.

There are others, but that's just off the top of my head. And even then, we're talking about often minuscule performance gains. As in microseconds minuscule.

Even if you can guarantee that your view models are immutable and tiny, the other conditions don't hold. Assuming one view model per request, your web server is not going to handle millions of requests per second. Furthermore, the MVC framework does not work with these in tight loops and does not contain code paths optimized for this particular struct. The MVC framework will end up performing tons of boxing / unboxing operations on your value types as a result.

Bottom line - don't micro-optimize or over-engineer your solution. Classes are just fine. And when optimization is concerned, always measure to make sure you're devoting your time to a worthwhile venture. Don't bother with trivialities when there are bigger fish to fry.

Levi
  • 32,628
  • 3
  • 87
  • 88
  • 1
    Thanks a lot for your time and thorough explanation, Levi. Your thoughts make my day. – Jonas T Jan 18 '11 at 13:38
  • 3
    Also, a struct is passed through the stack (more information to transfer) and the class is passed trough the heap via a pointer (less information to transfer). I know it's an old question but thought new visitors deserve to know more. – Miro J. Apr 30 '14 at 17:47
  • Brilliant summary thank you very much back to frying fish – Sigex Jun 02 '18 at 19:37
  • So @MiroJ I know it's like 5 years away but I really need to know. The company here uses struct as viewmodels. I told then I think it's not a good pattern. Am I Wrong? How can I defend it's not a good thing to keep doing or should I just forget about it. – Leandro De Mello Fagundes Feb 19 '19 at 14:50
  • IMHO. I think you should use the smallest possible object, which is the struct. Especially, when classes are intended to be complex (functions, constructors, etc.). At the same time, ASP.NET is so optimized now that probably it would not matter. Create a test and call a function 10,000 with one and the other option and see how they behave (time, memory, etc.) – Miro J. Feb 20 '19 at 16:26
0

use a class. some view models require constructors, converters and maybe more functionality, why limit to struct? (like if you have EF4 objects and you need to make POCO out of them...)

Dani
  • 14,639
  • 11
  • 62
  • 110