I’m working on porting a large vb6 application to .NET. The current app is a desktop app that communicates with a set of local access databases. There are about 200 forms in the application and about 100 tables. The screens are mostly complex. Most show master-detail relationships, lots of rows in embedded spreadsheet and dynamically generated editing controls.
They will port it to .NET. I’m not sure if they will want it web-based or winforms. To me, it seems that the application is better suited for winforms. Thankfully, the access databases will be replaced with sql server regardless of choice.
My reasons for winforms:
- Richer UI.
- Client caching
- Faster development. Winforms is productive for me even though ASP.NET is light years more productive than classic ASP. I would still rather work in winforms.
- Can display more data and spend less time concerned with managing state.
I plan to breakout the business/data layer into a seperate library. The business objects in the library will be able to be used either by the winforms or web app.
I’m thinking that if we port to winforms first and have a clean seperation of UI and business logic, I will be able to reuse the business logic in a web version at a later date. Given the business/data layer is in a seperate library with no UI dependencies.
In the end, it’s not my decision to make but I would like to hear your experience moving large windows apps to asp.net.
What was your experience moving a large desktop app to asp.net? How would you approach a project like this? Would you rather port this app to winforms or asp.net? Why?
Thanks! Steve
I would suggest that you do your port in stages to make the transition easier. The first stage would be to port from VB6 desktop to .NET desktop (win forms).
Then in the second stage, if still needed, you move all or parts of the .NET desktop to an ASP.NET GUI.
The step from VB6 to .NET is in itself quite large for a team to make, regardless of GUI choice. The staged approach would allow your team to get to grips with .NET in an application style more similar to the current app.
Your goal to separate business logic into re-usable libraries is therefore important for this staged approach to work. If you take this approach, you have much more flexibility about the GUI type (or types) used.
For example you could have all simpler screens provided in an ASP.NET website, with an auxillary WindowsForms app containing more complex screens that users can download as required. Importantly both of these would use the same business logic libraries, they are mostly just different interfaces to the same application.
ASP.NET (or web development in general) requires a quite different developer mindset when dealing with state, cross browser, html/css etc.
I recently worked on a port/migration of a large Delphi desktop app to .NET. The goal was to go to ASP.NET, however this fell over completely because the existing team had limited web development experience and tried to just re-implement the dektop app using ASP.NET. I’d say that this is a much bigger risk when compared to re-creating screens in Windows Forms, at least the end result will be usable and provide end-users some value.
While Ajax and jQuery have made great improvements to the richness of web GUIs, it sounds like your the existing app has some areas such as spreadsheet presentation of data that would be easier to implement efficiently in a desktop app.
In summary, the ‘ideal’ is to move the business logic and rules to .NET in such a way that you can then simply ‘plug-in’ a user interface at a later date. This may be much easier said then done, but that is the goal I normally aim for.