Almost 2 years ago, I asked a question how easy it would be to convert an application from WPF to Silverlight. The result was that I couldn't do it in a few days.
Now we are considering moving in the opposite direction. We have an application that looks like this:
So when converting, the server would just stay the same. We don't have any idea what time it would need to make the changes. We figure that we need to redo all Views, but besides that, we don't know for sure what modifications are needed.
Has someone did something similar before? How did you do it? What were pitfalls? And how did you plan it?
Any advice/tips/guidance would be great.
One thing that may put a wrench in things is if you're using the async web service calls that are in silverlight you'll have to translate them in WPF because until .Net 4.5 async web calls aren't well supported. (looking for a reference on that fact, if someone has that'd be excellent)
also WPF offers some easier ways to do some of the tasks around binding and data templates which may wish to be explored and may change some of the design
Related
I'm looking to create an interface which has drag-drop-dock functionality like Visual Studio. Telerik offers exactly what I'm looking for:
http://www.telerik.com/products/winforms/dock.aspx
Trouble is, it will cost $1000. This is a side project and I don't have a budget for that. Does anyone know of a similar control which is free and/or open source? Google didn't turn up any results.
Thanks
I ended up going more low-level and using OpenTk GameWindow and GWEN, which contains docking.
GWEN - GUI Without Extravagant Nonsense
https://github.com/garrynewman/GWEN
It's absolutely great, but unfortunately the original project is abandoned. There are a ton of forks at different states. I've personally had a lot of success with it.
I know such questions have been discussed here but have never seen them to be put it in this new light. We all know that WinForms isn't updated anymore by Microsoft. For client apps they are pushing WPF now. And people say WPF is harder to learn (I don't know, haven't tried really. And when I've tried I didn't much like it). But on the other hand, could that be it is just WinForms is perfect and there is nothing more to be done here?
WPF is in deed much harder to learn as WinForms. However it is really powerfull and gives you a lot of new possibilities. (I like the DataBinding-features and Templating really a lot).
WinForms on the other hand is very stable and is built on Win32. I'm sure it will be supported for a long time in future. But for me it's clear that microsoft will not extend the features if they have a new concept out there. Would you extend your old app, if you have a new one?
For me, I have switched already some years and I have never regreted the change. However, I have a lot of clienst with WinForms-apps, I built before and I don't have any hurry to update them to WPF. I never had a problem with WindForms, it is really a good and reliable product. As for your question: I think really WinForms is complete. It represents its time and has the features, this time had to offer. However, it's not perfect, no software can be perfect. Furthermore, I know also a lot of companies, developping new Apps with WinForms. MS will surely not letting die a technology for which so many apps exists. Look at XP, it will live longer than Vista.
Hard to learn is subjective.
I started learning winforms and WPF about the same time and I definitely feel more confident using WPF and feel I have picked it up quicker simply because I didn't have to "unlearn" winforms.
Sure, some WPF concepts are harder to understand at first but once they click into place you will start making progress and won't look back.
Saying that both technologies are great. Winforms Ace card is that it is mature, stable and easier to find help for.
Saying this, your question has a hint of "I'm not sure which one to choose so need someone to tell me" - The best advice is pick one and get on writing your application. Great applications can be written in both WPF and Winforms.
WPF is definitely better than WinForms, when you develop any LOB application its a high priority that how well you manage your code/project. When using WPF you have the power of following:
Separating your view from logic (the power of xaml, easier to read and design)
You can implement MVVM which gives you great control of your code. When working with multiple teams on a big project its a big plus.
On top of all that you can choose to use a framework like MVVM light, or use Prism 4.0 which not only helps implement MVVM but has other features too.
Another big advantage is, once you develop an application in WPF, you'll be able to develop in Silverlight with great ease. and with Silverlight 4 you have the capability of running your app out of browser without coding. Same app will run on desktop, cloud, web.
Finally I would say I wouldn't use WinForms because its 2011, WinForms is 90s...
Years ago (pre-web) I used to be a Fortran developer (yes it was a very long time ago!) but these days I run a small non-IT business. I would like to develop a database application for my clients to access via a browser (or maybe down the line via a mobile phone). I haven't done any programming for a while apart from some VB macros in Microsoft Excel. I would be grateful if anyone could suggest the best language/technology to learn to get me heading in the right direction.
As Neil said in his comments there are dozens of different, valid answers to this.
Usually I would suggest going with a language you already know, but neither Fortran or VBA are really suited for this task, as far as I know.
Personally I would suggest Django, which is a web framework written in Python. It simplifies many common tasks and it is very well documented.
But there are many more possible solutions.
Before I started with a framework I'd break the problem into pieces. If you've never done anything with a database before you'll find that challenging enough without piling web or mobile on top of it.
Model your problem and get a good object or data model in place. Test that thoroughly without thinking about UI. Once you have that, perhaps you can expose it as services that any UI can call.
You'll quickly become overwhelmed if you try to do it all at once.
Here's another thought: If these are paying customers, why not do yourself and them a favor and hire someone that knows how to do this? It's great that you used to write Fortran, but if you haven't kept up you won't be doing your business any good by putting out a bad first effort for customers to see.
Do it right - get a professional. Do your learning on your own time.
You can use ASP.NET and SQL Server to get something online that will allow users to edit a database table fairly easily. They've simplified it to the point where you can drag and drop the necessary controls (GridView and a SqlDataSource for instance) and define your datasource in a wizard for most simple table CRUD functionality. Basically give users the ability to edit a table without writing any code.
If you need to do something a little more difficult it's easy to write code that will add functionality to the original drag/drop stuff you did.
There are lots of good resources out there for asp.net and C# also, so it will help you get up to speed quickly.
Keep in mind that I work almost entirely with .NET/SQL Server so my opinion will be slanted towards them...
I really appreciate the question (and answers) we already have in “List of WPF functionalities that aren’t in Silverlight 3.” My allegedly new question narrows down the differences between WPF and Silverlight into the context of MVVM. Based on a Shawn Wildermuth MVVM sample project I downloaded from MSDN, I do see that, as of Silverlight 2, “Element Binding isn’t supported yet…” But this surely is just one detail and is this still the case? Is there a summary of MVVM-centered differences between WPF and Silverlight? Can we build our apps to move with more ease between the two technologies?
Update: Silverlight requires that calls to external resources be asynchronous whereas in WPF it can be synchronous or asynchronous. This requirement in Silverlight is due to the Web-based nature of the technology.
The pattern is identical, but the implementation may differ. Silverlight is missing some crucial pieces such as commands that mean you may need to put a little more effort into achieving an MVVM solution. However, at the end of the day, you'll still end up with M's, V's, and VM's.
Element binding is now available in Silverlight 3, along with a couple different options for implementing actions. There are behaviors, which are pretty easy to code, as well as commands if you use a framework like Prism (from the Microsoft Patterns and Practices team, not included in Silverlight by default). There's also the Visual State Manager, which is in Silverlight only right now, that handles a lot of the routine kinds of animations you might want if what you're doing is state-based.
Building apps to move between the two technologies is a different matter though. There are a number of XAML elements that are not supported on Silverlight (and some SL stuff not in WPF) and the underlying runtime is specifically kept small to facilitate web deployment, so there are and will continue to be a number of things missing. I don't think we'll see completely cross platform applications (code once, compile into both WPF and Silverlight without changes) in the near future and I think that in anything but the most trivial of examples the code revisions are going to be significant.
This doesn't mean that you can't apply MVVM to both or that the skillsets don't apply across both. If you are familiar with one, you're certainly 80% of the way there on the other immediately (that 20% can be tough though!) and understanding the pattern (I use databinding to get synchronization code out of the view and into the view model, I use commands/triggers/behaviors to remove actions from event handlers in the code behind of the view, etc.) means that you know what to do, even if how you do it is going to be a little different. From that perspective, I think we're about as close as we're going to get to achieving parity at a pattern level.
As for a summary of the MVVM pattern implementation differences between Silverlight and WPF, I haven't found one. Sounds like a good topic for a blog post from someone though...
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.