First I'd like to make it clear, I'm not looking for a "my tech is better than yours" type of post; this is a real case scenario and I have been faced with this decision. With this in mind, let me explain:
We have a WinForms application. It started in the early .NET 1.0 but the first shipping version was using .NET 1.1. There are layers (like BusinessLayer.dll, Datalayer.dll, Framework.DLL, etc.) but at some point during the "long" development cycle of this application, the "presentation" layer (Win Forms) got infected with some code, thus the "separation between the code and the presentation with code behind" is some sort of myth.
Bad practices or whatever, the truth is that the application is there and it works.
Years passed and we had .NET 2.0, we slowly migrated and it mostly worked, had to change a few calls here and there. Last version did the same thing, but for .NET 3.5sp1. We needed some sort of Webservices thing, and decided to use WCF instead. It works fine.
But despite all these .NET upgrades, most of the application's codebase is still the same old rock and roll from 5 years ago. We use Gentle.NET (old and unmaintained now) for our dataobjects (it was a blessing 5 years ago!).
Our presentation layer, the winforms, are "nice looking" since we employ 90% of completely gdi+ custom controls. (whenever possible without having to hack the WinAPi). The application is touch based (i.e.: it makes use of the Ink but it doesn't rely on that), but the buttons, labels, etc, everything is "designed" to be used with a tactile device. (TabletPC or Touchscreen). Of course some users use keyboard/mouse.
With all that in mind, and with all this web2.0 and Internet fuzz (plus Jeff's posts ;) ), we are considering the possibility of rewriting the application but using a web technology.
The idea is obviously bringing more availability for our customers (they can use the system whenever/wherever they want), and less maintenance (we can upgrade and it is an instant upgrade for 'em all), etc. You know, the usual Internet vs WinApp thingy.
The problem is that given that this is the healthcare industry, not all of our customers might be willing to "move" their databases to our server/s, which is acceptable, and would force us to install a webserver/database server in their own servers so they have their own copy. Not a big problem (except we would have to update those manually but that's not an issue, given that we've been updating win32 apps for 5 years now!).
Now, back to the main "question".
The team has little Asp.NET experience, we did program a lot in ASP 2.0 (in 1999/2000) but that was a spaghetti of HTML+VBScript+CSS, so I don't think it counts. After all that experience (the Internet bubble!) we went back to VB6 then C#.NET 1x and you know the rest of the story. We're a small team of C# developers for WinForms. We've acquired some Linq To SQL Experience in our last .NET 3.5 ride, and we liked it. We felt it very natural and very "if we would have had this five years ago…" like.
Given all this, rewriting the application is not a "simple task" (not even if we wanted to do it in the already known C#.NET), it would take time and planning, but we could correct dozens of mistakes and with 5 years of experience working with the application, we now can say that we have a better idea of how the customers would like to use the software and what limitations we created (by ourselves) when we designed the current app.
All that "knowledge" of the application and the way the business works, could be applied to produce a much better application in terms of design and code and usability. Remember in .NET 1.1 we didn't even have generics! ;) (you'll see lots of ArrayList's hanging around here).
As an additional note, we use Crystal Reports (and, as usual, we hate it). We don't think the ink control is a "must" either. The HTML/CSS could be shaped to look the way we want it, although we're aware that HTML is not WinForms (and hence some things cannot be reproduced).
Do you think that planning this in MVC (or WebForms) would be too crazy?
I like the MVC (ruby on rails like) idea (I've never programmed in ruby beyond the basics of the book), so no one in our team is an expert, but we can always learn and read. It mustn't be "rocket science", must it?
I know that this whole question might be a little bit subjective, but would you replace an aging Winforms application with a new ASP/MVC/XXX web application? Do you have experience or have tried (and had success or failed) ?
Any insight in helping use better decide what to do will be appreciated.
Thanks in advance!
UPDATE: Thanks to all who responded, we'll evaluate whether this is a good move or not, it sure is a hell of work, but I am afraid the the desktop app is getting older (using old net 1.1 hacks) and tho it has been more or less working without problems in Vista and W7, I'm afraid a future update may break it.
Also, lots of "more or less core" parts of the application are exposing some badly designed ideas and we had to hack here and there to accomplish certain tasks. Part inexperience, part lack of 100% knowledge of how the business worked (and Customers not sure what they wanted).
A new application (in any form) would allow us to create a better foundation while retaining all the user knowledge.
But, it's a L O T of work :) So we'll consider all these options here.
As some of you have mentioned, maybe a thinner client and some (ab)use of WCF here and there might be more appropriate.
Once again, thanks to all!
It would be best to ditch all your efforts of reusing the desktop application code when you recreate the web app. Following are the reasons:
Web apps especially asp.net use a different model. For starters note http is stateless. Each time the browser talks to server you have to explicitly send the current content of all the controls on the current page. You would not have used such a model in your Windows application.
To decrease load on the network you want to optimize the size of viewstate and how frequent you make http requests. Again your existing window app does not have any such provisions.
Updating view. You might have different event handlers, threads and what not in your windows application to update the GUI in different scenarios. All of that will need to be replaced. Javascript is a totally different animal.
Security. When using a browser your access to the local disk is highly limited whereas you will take the same for granted in windows application. If there is any code in the windows app that requires local resources, then that is going to be a trouble spot for you.
I would recommend the following:
Verify if your current application has any local disk access requirements (e.g. read/write to local file etc).
As you write the different http modules or handlers, you can try leveraging some of the backend/ business logic part of the existing windows application.
Give some thought to what part of your application can become a web service.
It sounds like the application needs a lot of refactoring to clean it up. If you want to move to a web model, and have maximum reuse you will really need to do that. Before you move to a web model I think you need to understand if it will be possible to replicate your user interface in that model. Is it your unique selling point from a customer perspective? You want decisions like this to be user driven rather than purely technical decisions.
It sounds like your application is the perfect candidate for a thick client application, rather than the lowest common denominator web model.
Some things to consider:
How will the web interface impact the Tablet interaction?
What new customers will having a web version bring you?
Will existing customers abandon your product?
Do you have access to consultants or outside resource with the right skills to mentor you in web technology? If you don't you can rely on StackOverflow or other web resources to help. You need some good mentoring and guidance on the ground with you.
What happens if you start this effort and it takes much longer than you expect? You know the app but don't sound like you know the web. Past experience shows that massive rewrites like this can end in disaster (it never sounds so difficult at the start)
Can you possibly write new features in a web-based version?
Could you move to ClickOnce deployment to make the application easier to deploy to customers. One of the benefits of the web is easier (zero) deployment. Can you get closer to that?
Would it be easier to migrate to WPF and create a browser application with that?
Silverlight or Flex might be better options for creating a rich experience, and may be more approachable for WinForms developers. Is this a possibility?
It seems like your app. is one of those that works best as a desktop app. Though you want your users to be able to access your app. using a browser.
I would suggest refactoring as much as possible so that the GUI gets cleaner and don't have "code".
When you've done this, start developing a asp.net mvc app but keep your desktop app. You should be able to use all layers except the UI layer, making it easier/faster/... Now that mvc exists, I'd say webforms is more about letting non-web devs do web. But you know web, sort of, and you want control so mvc is the way to go.
Related
I know this question was asked before, but almost 2 years have passed and the business requirements are a little different.
We are in the beginning of developing a mid-sized application and are divided which technology to use for the front end, WPF or ASP.Net MVC 3?
We are not an IT-company, but a business company with an IT-department who can outsource programming tasks, while the business core shall remain within the company. I did spend a lot time searching the internet for the answer, and I partially did succeed, but since the question is so important, I thought I ask here as well.
Of course, before someone can answer the question I need to specify the requirements and environment for the application at stake:
Infrastructure:
We have a pure Windows environment. Each user will have either Windows XP SP3 (currently) or a future version of Windows (if we skip from XP to Windows 8 remains to be seen, but let us assume that the user will use Windows 7 next) installed.
We are aiming for a service oriented architecture, meaning we only want to run/show on the client machine what is really needed. This is especially important since the databases are far away from the clients (USA/Europe). We plan on using WCF for cross machine communication between user system (brower or WPF), application and database server.
We expect the main user group to be around 30+, but since we are a growing company there should be no issue scaling up to 100 users. The users are spread over three main locations over the world, while we want the option to support smaller locations as well. All those locations are connected to the same intranet.
UI Experience
The new system is supposed to replace existing systems which are desktop applications (Winform). The number of screens are likely to be around 100+ with many labels, comboboxes, graphs. I like to call it an expert system b/c we expect the user to spend multiple hours a day with it, the user is expected to do interact fast with it (many clicks, multiple dialogs pop-up and close etc.) and the application will contain a lot of business logic (mostly mathematically).
Some limited interaction with Excel is required. At this stage only importing formatted data out of .xlsx file into the application in order to work with the data. This we expect to happen often.
Copy&Paste from Excel or other applications into our new application is a requirement (no pictures, just text).
We will use a vendor control library for a richer UI experience.
The users are used to desktop applications for their daily work (current systems/Excel etc.).
Tablet or smartphone support is not a requirement.
Deployment
If we were to use a WPF application we would likely either deploy it in CITRIX or use Click-Once.
Here are arguments of the two opposing factions:
Pro Web:
Deployment is much easier. All the requirements can be done in a web application directly, and if not we use ActiveX or make a separate desktop application for the missing parts. Also, the IT world is going to stop doing pure desktop applications and everything is moving to HTML 5 (Windows 8).
Pro WPF:
Web applications use many different technologies which makes it more difficult and costly to develop and maintain (HTML, ASP.NET, CSS, JavaScript, JQuery, AJAX). There are major deficiencies in a web-applications, mainly
Considering the various browsers and versions.
Screen resolutions
No hardware support for graphics (business graphs, point graphs with 200+ points)
Restricted access to local hardware (importing files, creating files, printing)
Keyboard shortcuts
Point #1 is also worrying since the browser is more out of control since other web-applications in the company (not expert systems) are used, and we fear conflicting interests with the new application (e.g., we must use a browser version where ALL applications run/render fine).
I know there is no black and white on this, but I would be interesting in the following:
Who was in a similar situation and how did they solve it?
(there is a nice article at http://karlshifflett.wordpress.com/2007/12/20/reasons-for-choosing-wpf-over-aspnet-for-very-large-project/, but the problem is that the article is 5 years old :(
How much more expensive is a web solution?
For development assume that the programmers are equally skilled in both (we can outsource this). For maintainance assume that we will internally support this where we have limited knowledge in ASP.NET and WPF. We know WinForm/WCF using C#. We would have to train/learn either technology.
How easy can a web application do Excel interaction, printing etc.?
I read a lot about "ActiveX hell" and I am wondering where we stand today?
Deployment
I have used Click-Once quite successfully in the past, although some team members mention that Click-once can be an issue. Any experiences?
Future?
The system is supposed to last 5+ years. We can not target HTML5 at this time (WinXP only up to IE 8). Where does Windows 8 stand on this?
Other thoughts?
What important things am I missing?
Thank you!
I know this entry is long and not an easy question. So I think you for reading and thank you even more for constructive feedback. Thank you!!!!
I would not build a business application in WPF, especially if your goal is to have it last for 5+ years. Silverlight is in sunset phase now - Win8 apps are betting on JavaScript and HTML5 now, though you are correctly noting that HTML5 support is not universal across all browsers and platforms (see http://caniuse.com/)
Let me try and address some of your concerns above to hopefully persuade you to build a web app:
Considering the various browsers and versions. Yes, you would have to do that. However, for enterprise applications most of the time you can find an acceptable solution if you use industry-standard web technologies and don't use esoteric HTML5 stuff that is not universally supported. It won't be a slam dunk, but it is very much doable.
Screen resolutions. You can address this by utilizing what is commonly known as Responsive Web Design. Once again, there is broad community and industry support for CSS frameworks that allow you to achieve responsiveness. YUI and Bootstrap come to mind as two examples.
No hardware support for graphics (business graphs, point graphs with 200+ points). Well, here is where HTML5 Hardware Acceleration may help you, but I'd say that libraries like HighCharts can easily handle 200+ points graphs - see this example
Restricted access to local hardware (importing files, creating files, printing). Fair point. I'd argue that working with files is MUCH easier with things like Socket.io, Filepicker.io and Zip.js, but "enterprise" requirements may get in the way. And as for printing, you can create "printable" version of your pages or generate PDFs and Excel Exports on the server side. Not ideal, but very much workable.
Keyboard shortcuts. Have you used Gmail app? It is full of shortcuts and keyboard-based interactions. This applies to any application - if you need keyboard interactions, you'd have to build them regardless of your choice of WPF or Web
After 9 month developing an enterprise application using MVC + JQuery our Management and stockholders interesting to convert and switch to silverlight! they think it's more powerful than Ajax, make development speed faster than our current solution, It's Windows and Web and less headache.
Unfortunately, our stockholders dos not know anything about web and stateless state of web application and they always compare with window applications.
But nobody in our team know anything about silverlight. I am not sure that is a good decision. I think we develop as fast as possible. we develop a great framework and code generator for fast develop.
Thanks and sorry for bad English.
Dumping what you have and going for a rebuild mid development is almost always a bad idea.
For a personal project, I did exactly this. It was originally built during the betas of asp.net MVC. I got the app to a stage where it was usable (actually I still use it daily), but it was nowhere near ready for the outside world. And this was the problem; it was going to take an enormous amount of work so that other people could use it...
When Silverlight 3 was announced, I literally grabbed the backend of the app - stuck RIA services in between and had a few screens up and running that day without any prior SL knowledge. I probably could have kept going down this path but something clicked when I started to realise the power of silverlight. The goal posts for my app moved, and I began a SL specific rewrite.
Since then, I've started re-writing about 5 times over. I guess I'm still just learning how to best build an app in SL, having spent the last 12 years or so of my career working on stateless web apps, there was a big mental shift involved.
I'm a much better web developer then I am a silverlight developer, but if it was for a real project (rather then a pet side project) - it would have been shipped and out the door by now.
I'm convinced that SL is the ideal platform for most web applications (as long as it being a plugin isn't going to be any issue).
With that said, shipping is still the most important thing. SL is great, but the learning curve is steep. If you guys are anywhere near completing the app, I'd insist you forge on with mvc and maybe get someone to build a SL branch.
Re-platform an application is always costly, although if you've got your MVC right it should theoretically be easier to replace the "VIEW" part of the application with something else.
As to whether Silverlight offers you more than HTML / JavaScript is down to what you're using it for. If what you are doing is media-related or highly graphical, Silverlight might be a good choice. If your application is like most business apps (i.e. some input fields backed by some read / write to database) Silverlight doesn't really offer any tangible time saving for this kind of operation.
If the web application is public and you care about search engine indexing, semantic HTML offers the best possible option.
I've been asked to do some work on an existing Silverlight project, mainly extending it a bit and doing bug fixes as needed. But there are a couple of ASP.Net pages too and a WCF service to deal with too. My background is desktop development with .Net so I think this is a good opportunity to start getting more involved in Web development.
So I'm trying to figure out what background knowledge I need for a project like this. Clearly I need to get familiar with Silverlight, but I'm not sure what other Web technologies, etc I need to ramp up on for this project. Obviously I would like to know as much as possible but in reality with limited time and resources I really need to focus on what I important in the near term for this project. Then expand my knowledge as things arise.
The things I'm thinking that are important in the immediate future are:
The basics of Web Development (I'm thinking this might be the most important\fundamental area to build a good foundation)
But what are consided the basics?
What is technology\language independent?
What is important for Silverlight?
The basics of ASP.Net (since there is some ASP.Net code)
What are the basics? ASP.net seems so huge, I have a 1000+ pg book here which seems daunting.
If you focus on Silverlight is knowing ASP.Net important, or is ASP.Net something I will continually run into?
How does ASP.Net MVC fit into the overall development picture and especially as related to Silverlight?
The basics of WCF
As compared what?
Any suggestions\comments on the list above?
What other topics\technologies will I run into if I continue doing Web development?
Note: Beyond this project I would focus on the Microsoft stack.
Generally speaking the amount of knowledge of ASP.Net you need to do Silverlight development is very very low.
Silverlight applications are hosted in a browser, usually via the <object> tag. This can sit on an asp.net page or a html page. The Silverlight template creates that for you, so you can forget its there and just get on with the Silverlight app.
Of course if you are integrating into an ASP.net environment (for example, islands of Silverlight sprinkled through an ASP.net site) then thats another thing. There are ways to get Silverlight talking to the HTML dom via the HTML Bridge but its not necessary. Really depends on what you are developing and integrating with. (new site vs existing)
I avoided ASP.net for as much as i could as the richness compared to desktop (WPF) just wasnt there. Silverlight changed all that. Its a Rich world on the web now!
Best place to start learning Silverlight is www.silverlight.net on the getting started part of the site. great Quickstarts and tutorials there.
Good luck
Only cursory knowledge of traditional web technologies (css, html, js, etc.) are necessary for silverlight development. As a consequence, you also don't need to understand the many cross-browser dependencies as well.
Here is my list of things that you must get a really good understanding of to be proficient at Silverlight development:
Understanding WCF (the Silverlight-supported parts) is essential. It can be a configration nightmare, but once working it is pretty stable/ reliable
You need to understand serialization used by WCF and how to debug the mysterious 404 errors. Get good at Fiddler and/or Firebug.
You must understand multi-threaded applications and how do debug them. Silverlight makes extensive use of threading to not block the UI thread. This creates numerous opportunities for race conditions that create what appear to be "magical" results. That said, it is incredibly powerful and IMHO one of the dominant reasons to use Silverlight.
What you learn about serialization and WCF will ultimately help you cache some data in IsolatedStorage. Learn about IsoStorage, it will reduce our bandwidth requirements and cost and improve your user experience
Learn about Linq - again this is one of the most powerful features of Silverlight. Combined with a smart client-side caching strategy you can offload lots of processing to the client.
Figure out how you going to support printing. SL3 does not at all and you will need a server side component. SL4 beta does, but it is not go live
Understand the Silverlight Roadmap as much as possible and plan out your roadmap to match/ sync with it as best as possible. I first built a SL2 app and I spent a lot of time building things by hand that were ultimately released in SL3. As it is getting more mature, there is less of this.
Download the Silverlight Toolkit and use it. But more importantly examine the source code, the structures, its build process. There is not better real world place to look for inspiration & best practices.
Good luck.
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.
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.
NESBAWA (Not Everything Should Be A Web App).
I worked for a company that went through a similar situation with their monolithic WinForms application. From that experience, 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 separation 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 separation 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!
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
We have a large suite of apps, most are C# 1.1, but at least 10 major ones are in VB6. We are undertaking a project to bring up the VB6 apps to .NET 3.5.
All the c# 1.1 apps are written using a traditional n-Tier approach. There isn't really any architecture/separation to the UI layer. Most of the code just responds to events and goes from there. I would say that from the point of maintainability, it's been pretty good and it's easy to follow code and come up to speed on new apps.
As we are porting VB6 apps, the initial thinking was that we should stick to the existing pattern (e.g. n-Tier).
I am wondering, whether it's worth it breaking the pattern and doing VB6 apps using teh MVP/MVC pattern? Are MVC/MVP winform apps really easier to maintain? I worked on a MVC-based project and did not feel that it was easier to maintain at all, but that's just one project.
What are some of the experiences and advice out there?
Dude, if something works for you, you guys are comfortable with it, and your team is up to specs with it. Why do you need to change?
MVC/MVP sounds good... Then why am I still working on n-Tier myself?
I think before you commit resources to actual development on this new way of programming... You should consider if it works for YOUR team.
If you are porting the VB6 apps vs. a full rewrite, I'd suggest to focus on your Pri 1 goal - to get asap to the .Net world. Just doing this would have quite a lot of benefits for your org.
Once you are there, you can evaluate whether it's benefitial to you to invest into rearchitecting these apps.
If you are doing full rewrite, I'd say take the plunge and go for MVP/MVVM patterned WPF apps. WPF willl give you nicer visuals. The MVP/MVVM pattern will give you unit testability for all layers, including the visual. I also assume that these apps are related, so chances are you might be able to actually reuse your models and views. (though, I might be wrong here)
It moves a thin layer of code you still probably have on the UI. I say thin, because from your description you probably have plenty of code elsewhere.
What this gives you is the ability to unit test that thin layer of code.
Update 1: I don't recommend to re architect while doing the upgrade, the extra effort is best expend on getting automated tests (unit/integration/system) - since you will have to be testing the upgrade works anyway. Once you have the tests in place, you can make gradual changes to the application with the comfort of having tests to back the changes.
MVC in particular does not exclude n-Tier architecture.
We also have ASP.NET 1.1 business application, and I find it a real nightmare to maintain. When event handlers do whatever they like, maybe tweak other controls, maybe call something in business logic, maybe talk directly to the database, it is only by chance that software works at all.
With MVC if used correctly you can see the way the data flows from the database to your UI and backwards. It makes it easier to track the errors if you got the unexpected behaviour.
At least, it is so with my own little project.
I'll make the point once again: whatever pattern you use, stick to the clear n-Tier architecture. 2-Tier or 3-Tier, just don't mess everything into a big interconnected ball.
"Change - that activity we engage in to give the allusion of progress." - Dilbert
Seriously though, just getting your development environment and deployment platforms up to .NET 3.51 is a big step in and of itself. I would recommend that things like security reviews and code walkthroughs should probably come before re-archecting the application.
MVC and MVVM are excellent paradimes, particulary in terms of testability. Don't forget about them, but perhaps you should consider a pilot project before full scale adoption?