Best introduction to MVC?

[tempto]

I'm already a ASP.NET WebForms developer and I would like to jump to MVC. Which books/courses would you recommend me? As far as I know, MVC has evolved to ASP.NET Core am I right?

 

[Absalom]

Technically, everything is moving to .NET 5...

But to answer your question, yes, ASP.NET Core MVC is where MVC has moved to. Start learning razor pages, if you haven't already. Bring your HTML, CSS, javascript, jquery, bootstrap, etc. skills with you, you'll need them.

I self-taught myself ASP.NET Core MVC fairly quickly, so I'd say skip the books/courses. There's enough free knowledge out there on the internet, you just have to know where to look. Start with Microsoft's Overview of ASP.NET Core MVC. Get familiar with the terminology and high level concepts. MS's examples are a good start, but a bit boring. If you're not afraid of jumping straight into it, take a look at IdentityServer4 and their Quickstart guide. The server they'll have you build is MVC based (ASP.NET Core 3.1 to date). It's a real world example, and you'll end up with a working OIDC authentication server at the end of the tutorial. Who knows, you might end up using it later on. So, bonus.

However, I'd recommend skipping MVC altogether and jumping straight into ASP.NET Core Blazor. Blazor is far more cutting edge than MVC. If you care anything about a responsive or rich user experience, SPA web design is where it's at today. With Blazor, you're writing things in C# instead of Javascript. And if some 3rd party thing you want is already is written in Javascript, you can just wrap it with a little C# and reuse it. No need to reinvent the wheel, I say.

I've spent the past 11 months learning and developing with both MVC and Blazor, and Blazor pretty much blows it out of the water. Sure, you can pull off some of the things Blazor does with MVC, but you'd have to write a ton of Javascript. I'm more of a C# developer, so Blazor was the better fit for me. I found out I like writing reusable REST APIs far more than MVC-centric controllers. If you go Blazor WASM for a client, you'll be writing a lot of REST APIs for your backend. Of minor note, I also found debugging in Blazor a lot less annoying than MVC. Another neat thing about Blazor WASM is with minimal effort you can convert your existing project into a locally run app (think React/Electron). You can't do that with MVC.

 

[tempto]

Thanks to your recommendations I have discovered Blazor, which is pretty new by the way, it comes with Visual Studio 2019.
Web Assembly looks really interesting. Running an app locally with WASM is multi-platform?

 

[Absalom]

Thanks to your recommendations I have discovered Blazor, which is pretty new by the way, it comes with Visual Studio 2019.
Web Assembly looks really interesting. Running an app locally with WASM is multi-platform?

Yeah, WASM seems weird at first. But browsers are so advanced these days, we're no longer on dialup, and the hardware they are running on is light years ahead of anything fifteen years ago, so why not?

You're basically compiling into byte code, hosting it on a server, then letting the browser download it. After some clever bootstrapping, it runs the app natively in the browser.

Being an SPA, your app is essentially manipulating the DOM, so it's no different than javascript. At least your byte code isn't in clear text for everyone to peruse.

The only disadvantage I've seen thus far, at least with Blazor, is the entire app's assemblies have to be downloaded. Not an issue if your footprint is small. If the browser has a good cache strategy, then it's a one time thing anyway.

One other counterpoint, old and outdated browsers don't support WASM. So your grandma stubborn in her ways still on IE10 is SOL. Not necessarily a bad thing, imo.

 

[Epos7]

Blazor is very cool. The naming strategy for the hosting models is a little confusing, as Blazor Server is not WASM.

 

[tempto]

SPA is used both WASM and Blazor Server or only WASM? And loading content dinamically is similar to callbacks? WASM should be used for small projects right?

 

[Absalom]

SPA is used both WASM and Blazor Server or only WASM? And loading content dinamically is similar to callbacks?

They are both SPA. The difference is where the code runs. In a Blazor WASM Client your code is being executed locally in the browser. In a Blazor Server (i.e. non WASM) your code is running remotely on a server.

In a non-WASM setup, the browser presentation is just a mockup of its UI components. Think of it more like a remote desktop experience. You click on a button, the click event has to be sent to the server and any resulting UI updates have to be sent to the client. Any delay between clicking the button and updating the screen has to complete a full round trip before the user sees anything. This is the price of all-in-one development simplicity.

With a Blazor WASM Client, you need both a client and server, so basically two projects. Well, I suppose you could write a pure client, but it would be useless if your database isn't local. Anyway, the client is obviously written in Blazor. The server can be almost anything. It typically isn't Blazor. There can be more than one server. A REST API is the obvious choice. Regardless, you still need a server because the browser has to have a way to download your client. So if you've already got an Apache server up and running, you can package your WASM client's assemblies and deploy them as static files. If you already have an ASP NET server project you'd like to use/recycle, you can try that. Again, the server doesn't have to be Blazor, much less ASP NET. Regardless, you still have to write client code to handle the HTTP requests and responses. However, you don't have to write the code that downloads your client to the browser, as that's already taken care of by the bootstrap.js running in the browser when the page loads.

WASM should be used for small projects right?

It's a matter of preference. The project size doesn't matter. In theory, a WASM client could get bloaty (i.e. a ton of DLLs, static files, etc.), thus making the initial download take some potentially obnoxious amount of time since it has to download the whole thing. But once the client is up and running, it's good to go. A non-WASM client would upload user inputs and then download screen updates. So not a lot up-front, but over time could be potentially wasting bandwidth. I suppose in a WASM scenario if you're not careful about pruning the data you are requesting (i.e. sending all rows) you could be doing things more inefficiently. There's a finesse to doing a pure client.

If anything, I'd use non-WASM for something really simple and when user input response isn't a priority.

A good example to contrast either is having a list of unsorted items on the screen. The user clicks the button to sort them. In a WASM scenario, there's no need to bother the server again, the data is already there. You simply leverage the client's PC to sort the list. With non-WASM, you have the round trip, plus the server has to sort the list. Multiply that by thousands of users doing it simultaneously (contrived scenario, I know), and you've got a server loaded with requests.

It goes without saying, large data sets are more efficiently handled with a non-WASM client.

 

[LFaWolf]

If you are still looking for courses, I recommend PluralSight. You can sign up for a new Outlook webmail, sign up for Microsoft Dev Essential, and you get 30-days of free trial of PluralSight. With your background, a few courses in ASP.NET Core should get you well on your way.

 

[Bigbacon]

Technically, everything is moving to .NET 5...

But to answer your question, yes, ASP.NET Core MVC is where MVC has moved to. Start learning razor pages, if you haven't already. Bring your HTML, CSS, javascript, jquery, bootstrap, etc. skills with you, you'll need them.

I self-taught myself ASP.NET Core MVC fairly quickly, so I'd say skip the books/courses. There's enough free knowledge out there on the internet, you just have to know where to look. Start with Microsoft's Overview of ASP.NET Core MVC. Get familiar with the terminology and high level concepts. MS's examples are a good start, but a bit boring. If you're not afraid of jumping straight into it, take a look at IdentityServer4 and their Quickstart guide. The server they'll have you build is MVC based (ASP.NET Core 3.1 to date). It's a real world example, and you'll end up with a working OIDC authentication server at the end of the tutorial. Who knows, you might end up using it later on. So, bonus.

However, I'd recommend skipping MVC altogether and jumping straight into ASP.NET Core Blazor. Blazor is far more cutting edge than MVC. If you care anything about a responsive or rich user experience, SPA web design is where it's at today. With Blazor, you're writing things in C# instead of Javascript. And if some 3rd party thing you want is already is written in Javascript, you can just wrap it with a little C# and reuse it. No need to reinvent the wheel, I say.

I've spent the past 11 months learning and developing with both MVC and Blazor, and Blazor pretty much blows it out of the water. Sure, you can pull off some of the things Blazor does with MVC, but you'd have to write a ton of Javascript. I'm more of a C# developer, so Blazor was the better fit for me. I found out I like writing reusable REST APIs far more than MVC-centric controllers. If you go Blazor WASM for a client, you'll be writing a lot of REST APIs for your backend. Of minor note, I also found debugging in Blazor a lot less annoying than MVC. Another neat thing about Blazor WASM is with minimal effort you can convert your existing project into a locally run app (think React/Electron). You can't do that with MVC.

I shoumd try blazor. Im c# guy also but i still absolutely love javascript.

My boss would kill though. Trying to get him using mvc for a few yesrs now. He finally learning enough to be dangerous.