I'm a fairly experienced desktop .NET developer with a solid feel for MVVM and WPF, and I've worked with JavaScript, jQuery and HTML/CSS in the past - though I'm pretty dated and haven't had a ton of experience with the new frameworks (Angular, et al).

My question is, for anyone who has had to do it, what are the key pain points and differences I should be aware of when working on an ASP.NET MVC project?

I have a general sense of the MVC pattern and where it differs from MVVM, but ASP.NET tricks me by looking familiar, but with subtle and not-so-subtle differences in implementation and execution. I'm helping out with an ASP.NET project at work, and while my C# knowledge helps, my desktop habits seem to be a liability. Links to material I can review would be appreciated, or a succinct summary of what I need to change about my mindset.

closed as too broad by gnat, Dynamic, user40980, Bart van Ingen Schenau, amon May 8 '14 at 14:05

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 6
    I would say they are completely different technologies with completely different ways of design. Especially if you account client programming. – Euphoric May 6 '14 at 18:58

I went from MVC to MVVM and found that the main difference is that with MVC you deal with a single request from Controller to Model to View over and over, which you can turn into a single-page type app with AJAX.

In MVVM, the async of data/view is taken care of via properties notifying anything bound to them that the value has changed. Your Views can refresh themselves without having to re-do the entire MVC call and re-draw everything - instead only the affected properties are re-drawn so to speak.

I've found the async nature of MVVM to be favorable over MVC. The biggest hurdle for me has been trying to adhere strictly to MVVM pattern and not putting code in View Code-Behind or make Models/VMs aware of any Views etc. For smaller projects, it doesn't really matter.

Over-simplified example:

MVC: $user submits login request through controller, controller builds new View with $user defined from Model

Controller [$msg = Hello, $user!] => Model [$user = Bob] => View ["Hello, Bob!"]

MVVM: $user submits login request through view, view model updates property with $user defined from Model, Property Notifies View that it has changed and View is updated (without having to re-draw or re-submit the entire process)

ViewModel [$msg = Hello, $user!] => Model [$user = Bob] => View ["Hello, Bob!"]
  • Wow, that's a good explanation of the differences. Thanks! – Vernacular Ham May 6 '14 at 21:10

It's a totally different beast. WPF is all about binding your ViewModel with the views using XAML. There are frameworks (I think Caliburn Micro is the one I used once) that help building this bridge automatically hence allowing you to reuse more code.

On the other hand, ASP MVC is about using a template for your C# objects, but once your page has been served, you usually need more programming on the client side. Name it JQuery, Knockout, AngularJs, etc. This way you can make bindings for each control, kind of what XAML does, but with more power in my opinion.

As you learn more about how http request/response cycle works, believe me, you will crave more and more programming in the browser and less on ASP side. At least that was what happened to me. Nowadays I use C# as a console application to serve/recieve JSON, serialize/deserialize and read/write in databases. Even the attempt to put logic on ASP views is not appealing to me anymore. Plain HTML happens to be a great fit for javascript without the need of server templating.

  • Yeah, I was never a huge fan of working with ASP, but a lot of corporations seem to use it extensively, and the specific project I'm on calls for it as a requirement. – Vernacular Ham May 7 '14 at 15:20
  • Fully agree, it becomes more a corporate requirement that a matter of choice. Good luck then. – mau May 7 '14 at 22:12

Not the answer you're looking for? Browse other questions tagged or ask your own question.