CODEWITHSUNDEEP
wpfasp.net-mvcwinformsmodel-view-controller
tomomomo
tomomomo

Reputation: 157

WPF/Windows Forms application easy to move to ASP.NET (MVC?)

For my .NET project on my studies I need to write an enterprise application that will first be a desktop application (both WPF and Windows Forms are availible for us) and then will be extended and will serve as a web application (ASP .NET preferably). I wanted to use the MVC design pattern so that I could possibly change only the UI while doing this but it seems to be kind of hard. I read a lot and figured out that the idea of MVC in WPF is realized by the MVVM but I read that it is not very easy to migrate it to ASP .NET MVC and this is what I want to use in the second part of my project. I would greatly appreciate any hints regarding this as I don't want to rewrite the whole application from scratch...

For data handling I wanted to use the Entity Framework. I found some nice tutorials on how to combine it with ASP .NET MVC and I will probably find a lot that work with WPF or Windows Forms and some MVC implementation. The question is, what should that be? What would make moving to ASP .NET MVC the easiest for me?

Upvotes: 0

Views: 5424

Answers (1)

Claies
Claies

Reputation: 22323

Your question is pretty broad, but I'll try to give you a bit of guidance. When dealing with Enterprise Applications, you generally have multiple tiers. In general, the more tiers you can break your application into, the better. Commonly, you would have, at minimum, a Data Tier, a Business Logic Tier, and a UI Tier. A properly architected application would allow for multiple different UI Tiers (WPF, Silverlight, ASP.Net MVC, etc.) to all communicate with the Business Logic tier, which in turn would then communicate with your Data Tier. If you decided to change the storage from one medium to another, such as changing from SQL to MongoDB for example, those changes would happen on the Data Tier and should have little to no impact on the Business Logic, and no impact at all on the UI. In the past, WCF was popular for building the intermediate Tier, but more recently, ASP.Net WebAPI is becoming popular due to it's RESTful nature.

So in a basic application for your design you might have 5 projects:

  1. Data Project, containing Entity Framework and related database entities, exposing CRUD operations for the WebAPI project to consume.
  2. WebAPI project, containing RESTful API for generic access to data for the UI projects to consume. These methods perform business validation, error checking, etc. before calling off to the CRUD operations in the Data Project.
  3. WPF project, providing desktop UI and desktop specific features.
  4. ASP.Net MVC project, providing web access and web specific features.
  5. Unit Test Project, for functional verification that changes in one project do not cause features in another project to break.

Other projects may be sprinkled in, like, say, a Pure JavaScript project, or a SignalR project for realtime notifications.

Edit

For very small projects, either the MVC or MVVM patterns are merely extensions of this concept, boiled down to fit a single project.

MVC is the web framework take on things, where you have a Model (Data Tier), a View (UI Tier), and a Controller (Business Tier). MVVM is a Model, View, and ViewModel. This difference is mostly related to the fact that on the Web, Page navigation is handled by the Controller, which is on the server side, while in a WPF application, Page navigation is much more likely to be handled in the View. In even the smallest project, you will need to re-create the UI between a web project and a WPF/Webforms app, and the Controller / ViewModel are platform specific as well, but there's no reason at all you couldn't re-use the Model Tier. Really there aren't enough similarities between a desktop project and a web project for significant re-use, which is why segmentation and adding a WebAPI project minimizes the amount of re-implementation per platform.

Upvotes: 5

Related Questions