Why is ASP.NET MVC limited to ASP?

Question

Duplicate

MVC .NET For the Desktop?

I've developed some ASP.NET MVC apps, and loving the framework. However, one thing I don't quite understand is why it's limited to web UIs. It seems like one of the reasons for a separation of the view and controller is to allow for multiple views to reuse the same controller logic. For example, I should be able to hang a WPF UI on the same controllers as the Web UI. I suspect, though, that I'm misunderstanding something fundamental about separation of concerns. Is there a reason ASP.NET MVC controllers are limited to use in web applications?

Update: I'm less interested in "is it possible to do MVC on the Desktop" - I know Prism, etc. allow this. However from a design standpoint, one of the "reasons" we want separation of concerns is for reusability. If we can't reuse the controllers, it feels like we're repeating ourselves when rewriting identical logic in a WPF app. The answers below do clarify this some for me though.

Answer 1

ASP.NET MVC is a framework for doing MVC with ASP.NET; it includes things like URL routing and so forth. You can very well do MVC (Model-View-Controller) style programming with WPF and WinForms.

Answer 2

Here's a previous question where I tried similarly - let's see what we come up with this time.

Another aspect of this question is why does VS have so little in the way of abstracted design tools that can be used for both .NET desktop and asp.NET development?

Answer 3

Model View Controller is a pattern, ASP.NET MVC is that pattern applied to ASP.NET's web framework. As its been mentioned, this ties url routing into things to make navigation simpler and more integral to how actions are called.

That said, nothing is technically preventing you from using components in ASP.NET MVC libraries. The data access layers via LINQ or Entities are available outside ASP.NET MVC. Likewise, the pattern itself has countless examples of its implementation for Winforms applications. The same techniques could be applied to WPF.

Answer 4

I have to say the the MVC model is specially practical in web apps, and that's because the view (the html page) is really disconnected and far away from the controler and the model.

In desktop apps, that is not the case, and you will be soon missing some opportunities the break the pattern to make the app more useful.
For example, you can't do the powerful and time-saver databinding in WPF, because it breaks the MVC pattern.

A good pattern used in WPF is M-V-VM

Answer 5

I wouldn't say you're misunderstanding separation of concerns at all, in fact your question indicates you understand it well.

The name "ASP.NET MVC" shows that Microsoft made a concious decision to create a more specialized implementation of MVC for w3eb based applications. This allows them to optimise the design to make it more productive for developers building web based applications and services.

If they had created a more general ".NET MVC" framework I would expect it would require a much more difficult trade-off between the needs of web applications versus desktop applications.

Personally, I think Microsoft's approach can make it more confusing for less experienced developers who often assume that the implementation of the pattern, is the pattern.

Answer 6

Easy to say this, I know, but if you implement your data access layer and business objects well, it is possible to reuse a significant portion of your code.

We are using ASP.NET MVC. We have a seperate project where we have our business objects, and our data access layer. Our 'models' in the web project are generally lightweight wrappers for our business objects.

Our controller methods are all pretty lightweight, as between the data access layer and our business objects we have encapsulated and simplified much of our business logic as presented to their consumers.

Once we had built our MVC application, we wanted to use some of our data in a WPF application (for a status display screen). We just created a new project, referenced our data access layer and data model and we were away. Really straightforward, and plenty of code reuse.