Ever since I started working for my current employer (my first real programming job) I keep trying to understand why WebForms (what we currently use) tries to avoid multiple calls to the DB by using ViewState to hold data temporarily. I personally prefer the MVC and WebAPI frameworks over WebForms and have spent a lot of time playing around with them in ASP.Net Core. At my job, we often talk about the more efficient method for persisting data based on different scenarios, i.e. ViewState, Session, additional database calls, hidden fields or query params.

I know that MVC eliminates many issues of ViewState (such as the infamous multi-tab problem where ViewStates become corrupted) by removing it altogether, but my boss always says to avoid additional database calls at all cost. I noticed that most MVC implementations use Entity Framework and the amount of calls seems insanely high. I have also heard that you should avoid session variables whenever possible (our internal website defies this rule to the extreme by putting the entire Application Context object inside of it! Not a big issue as it's only an internal website but it has shown multi-problems with tabs as well).

I was wondering if the newer frameworks are more efficient with database calls. Is it to do with EF's method of lazy loading (possibly calling them all as a transation or something)? I'm just guessing. I don't know why this is no longer a big issue. How do the newer frameworks, or newer principles used by developers, handle ViewState for times when you want to avoid database calls?

With WebForms, the main issue is that there are so many event handlers that require sending back the whole webpage to the server just to check if a dropdown list has changed it's index value, for example, and I think MVC and WebAPI avoid all this entirely by replacing the design paradigm altogether.