Tips for developing on WinForms thinking on a future Web developing

Question

We are developing/mantaining an enterprise application which for historical reasons and development speedup it was targered for WinForms.

Now we are thinking that sooner or later (more sooner than later) that application will need to be Web based.

Thinking on the "to-Web" movement. Which are the most important things we have to consider? Something like, thing on MVP parading (or others), determine now the kind of platform/framework you are going to use, ...

Any experience on migration from winforms to web? Any suggestion to take care?

Aclaration: In our scenario the application would be nice NOW to be Web based but we are realistics. I agree that not all the applications have to be Web based (this is the main reason we developed with WinForms!). But sometimes the requirements changes and, in our scenario, we want to offer that application as SaaS.

Answer 1

NESBAWA (Not Everything Should Be A Web App).

Answer 2

The main thing is to completely separate the user interface from everything else. Once you've done that, you won't be rewriting the application in order to port it - you'll just be creating a web UI on top.

Answer 3

John is right. However, have you heard of the "Empty Client" approach? This is a fairly new approach to developing .NET WinForms applications that can also run as web applications on plain browsers. That approach would allow you to develop your WInForms application and put it on the web if and when you desire with no additional development or adjustments. One framework that does it is Visual WebGui

Answer 4

I worked for a company that went through a similar situation with their monolithic WinForms application. From that expereince, there are two things to consider:

1] Decouple all data access logic (DAL) from the existing WinForms UI. You can start this process before any web development begins.

We did this refactoring in a series of 6 weekly sprints. Some parts of the app were easy to change - others were made of completely hellish spaghetti code that interwove DAL, inline SQL and UI code all in the code behind of the WinForm.

Once you have this sepeation in place, supporting two different UIs is easier.

2] Ignore ASP.Net MVC and target WebForms. WebForms was designed to make writing a web application close to the experience of writing traditional WinForms UI code (event driven, component based).

You need to understand the page lifecycle, and there are a few conceptual gotchas around dynamically generated controls that tend to trip up a lot of newcomers - but otherwise it's the most painless way to get a team of WinForms developers doing web stuff. MVC maybe very popular in web circles right now, and it provides a better seperation of concerns (though you can achieve similar results with WebForms with a bit if diligence and strong design leadership) - but it requires a higher degree of knowledge. With MVC you're working closer to the metal of the HTTP request/response cycle. WebForms abstracts away a whole lot of that for you.

Best of luck in your endeavour!