I know there are other issues involved in any decission when beginning a large project, but my experience in the past has been with SL web based apps (w/ entity framework) where I have found wcf ria services such a time saver, I am wondering what people think about the reasons one might remain with wpf for desktop apps where so much more effort must be expended to match what the ria services provide in SL. This project is definitely a data-centric business app.
Any and all oversvations and experiences would be most welcome.
Thanks,
Steve
I may have some insight on your situation, since I am faced with making the same decision right now. I wrote up a blog post about my experience here:
http://samuelmueller.com/2010/11/wpf-4-vs-silverlight-4-which-do-you-choose
To summarize, WPF has one very big advantage over silverlight, especially with data-centric apps:
Performance.
With that being said, the list of negatives is quite daunting, and really makes WPF a hard sell over Silverlight:
No support for WCF RIA Services, even with SP1
Sub-par validation support, with INofityDataErrorInfo missing
The WPF toolkit has been practically abandoned, whilst Silverlight toolkit and theming are very much active.
No Fluid UI
If you can live with the performance, it seems like Silverlight is the more productive and compelling choice, at least until MS makes some effort into leveling the two platforms.
The thing is, Microsoft seemed to have developped WPF at the beginning, but failed to really keep it fresh. On the other hand, they are working on improving Silverlight, releasing new version almost every years.
I still like WPF over typical windows forms and find that not having RIA services isn't much of a problem since you can still access databases the way I am used in normal Windows Form.
Related
We are a team of .net winform and asp.net developers building custom enterprise applications for organisations mainly in the public sector. Is it time to retrain/retool the team in WPF/Silverlight? How to make management, in first place and clients second buy the idea?
Clients shouldn't care, necessarily. You'll convince clients by showing them how you can be more productive and succeed in their goals, not by explaining tech. to them.
Management, on the other hand, is trickier. You need to convince them of the arguments for using WPF or Silverlight vs. Windows Forms. This can include:
Easier maintainability, especially when designed properly
More flexibility
More options to gain a competitive edge, via using new techniques such as better graphics/etc
Better support/lifecycle, since the newer technologies are actively developed and improved by Microsoft
Better deployment options (particularly with Silverlight), allowing for more flexible deployment strategies
Personally, I think that with VS 2010, WPF is finally mature enough to be the only option. Previously it was held back by performance issues, poor text rendering and a lack of out-of-the-box controls.
Here's what Rocky has to say, and I completely agree with him:
Silverlight and WPF both compete with
Windows Forms. Poor Windows Forms is
getting no love, no meaningful
enhancements or new features. It is
just there. At the same time,
Silverlight gets a new release in less
than 12 month cycles, and WPF gets all
sorts of amazingly cool new features
for Windows 7. You tell me whether
Windows Forms is legacy. But whatever
you decide, I’m surely spending zero
cycles of my time on it
http://www.lhotka.net/weblog/ItIsOnly8HowCanItBeLegacy.aspx
Before you go down that path, have a careful read of the Silverlight 4 news that is coming out of PDC. You will end up doing a mix of both Silverlight and WPF, it is unlikely that you will end up doing only one, and they are sufficiently alike that skills from one can be used in the other. However you don't want to be wasting money and time on Silverlight training that is out of date, as Silverlight 4 will be no more than 6 or 9 months away from being released (possibly sooner). Therefore you may want to do the WPF training first.
To add to what #Reed said:
faster development cycle (once the developers are familiar with the technology)
very easy to do automated testing, including automated UI testing
Is it possible for you to step towards WPF by embedding a WPF app into one of your existing WinForm applications?
It can be a lot harder to sell a complete retooling without an example of some of the benefits (in particular, maintainability and flexibility, especially in the UI). Try starting with a well used portion of your current application and giving a demo with it in WPF.
I'm looking at Silverlight architectures and RIA Services looks interesting, but I am a bit concerned about its prelease status and how the feature set will change.
We need our client app to be as responsive as possible over a slow network link, so a high priority is a solid sync system for pushing model state changes from the client back to the server. Will RIA Services help us in this regard or will I have to roll my own logic to do this ? Are there any other frameworks that can assist with this? Is the feature set involved in these requirements liable to change much in the next couple of months?
If it makes any difference, our frontend is 100% Silverlight, so we dont need to worry about exposing SOAP APIs from the server or anything like that. It appears to me that RIA so far is a bit more mature for Silverlight use. Is this correct?
I am using SL 3, .NET RIA and EF. Still trying to figure out how to load, and update data effectively and best in performance. Little information that I have so far how to improve the performance issue that I face. Still need more time to get these frameworks to be mature. Hopefully, there are more resources and insight in the near future.
My take is if you are handling very light data application, silverlight can be a good choice. Once you have loaded the application in to your machine, it is like loading application within your box.
I would look into some of the ORM's / IoC Frameworks which help create a separation of interests. A couple examples are Castle Windsor IoC, they have a sample Silverlight 4 application that utilizes the Castle Windsor Framework. Another common ORM for Silverlight is
BL Toolkit. These have been around for a while in the Java arena but are newer in the .NET area. They basically help to move the complexities of the relational data model out of the UI code and delegate it to the Framework.
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
It seems that Silverlight/WPF are the long term future for user interface development with .NET. This is great because as I can see the advantage of reusing XAML skills on both the client and web development sides. But looking at WPF/XAML/Silverlight they seem very large technologies and so where is the best place to get start?
I would like to hear from anyone who has good knowledge of both and can recommend which is a better starting point and why.
Should you learn ASP.NET or Winforms first? ASP or MFC? HTML or VB? C# or VB?
Set aside the idea that there is a logical progression through what has become a highly complex interwoven set of technologies, and take a step back and ask yourself a series of questions:
What are your goals; how do you want to balance profit against enjoyment
Are you short term oriented or in for the long haul
Are you the type of person who likes to get good at something and do it a lot or do you get bored once you fully understand it?
The next and hardest step is to come to accept that any advice you are given is bound to be wrong; and the longer the time horizon the more likely it is to be incorrect. If the advice is for more than six to 12 months, the probability the advice is wildly incorrect approaches 1.
I can only tell you my story, quickly. In 2000 I was happy as a consultant working profitably in C++ on Windows applications, writing about ASP.NET and WinForms. then I saw C# and the world turned upside down. I never went back.
Two years ago I had the same kind of revelation, only an order of magnitude bigger, stronger and with more conviction about Silverlight. Yes, WPF is magnificent, and it may be that I'm all wet about this, but I believe in my gut that Silverlight changes everything. There was no doubt then and there is no doubt today that Silverlight is the most important development platform for Microsoft since .NET (certainly) and possibly since the switch to C++.
In a nutshell, here is why. I don't understand where its limitations are. With most platforms I do: you can do this, but you can't do that. WPF is a pretty good case in point, as was ASP.Net and WinForms and, well really everything until now.
With Silverlight, I don't see the boundaries yet. Silverlight has already leaped off the desktop onto phones, and I don't see any reason for it to stop there. Yes, it is true, it is bound by the browser, but I see that less as a jail cell than as a tank in which Silverlight will be riding over lots of terrain (it must be very late, I should go to bed).
In any case, for now, learning Silverlight is a gas, there is a lot of material on the Silverlight.net site, and what is the very best thing about learning Silverlight is that if you don't see what you need you can holler at me and I'll make sure you get it pretty quickly.
Enjoy, good luck and the dirty little secret is you'll be fine whichever you choose. It's all just software.
-jesse
Jesse Liberty
"Silverlight Geek"
I'd say go with Silverlight first!
I have programmed with WPF and Silverlight before.
But as Silverlight is a subset of WPF if you go in too deep and try to switch to writing Silverlight applications, you'll be scratching your heads looking for that "tag" you learned to love in WPF but is not available in Silverlight.
When you master the basic things in Silverlight first, the extra mechanism/trigger/whatever features in WPF will simply add to most of what you've already known.
Silverlight in WPF differs at the features level, not just some missing controls or animations. Take the WPF triggers mechanism for example, is not available fully in Silverlight.
So learning the smaller subset first, you can extend that knowledge to the full set later, but if you started at the full set and gets addicted to some of the niceties available, you'll have trouble down the line when someone asks you to port your designed-utilizing-WPF apps to Silverlight.
I'll go against the grain and say learn WPF first.
Here's my reasoning:
Much more resources are available for WPF than Silverlight, such as books, blogs, and msdn documentation
WPF Books
You're not dealing with a Beta, moving target
You don't have to deal with working with only asynchronous calls
Not limited by lack of features such as Merged Dictionaries, Triggers, TileBrushes, etc.
You don't have to worry about re-learning to do things correctly because of lacks of features in SL
Silverlight is a stripped down version of WPF so it should have fewer things to learn inside. On the other hand, the two platforms have different targets (web & rich client) so I guess it depends on what app you're going to build.
If you just want to learn for yourself (no app in the close future) I'd pick Silverlight because it would be less to assimilate. Still, Silverlight is pretty much a moving target, much more than WPF, so you'll have to keep up with some changes from time to time (the joys of being an early adopter :)).
WPF has lots more stuff that you will probably want to use at some point but I would wait for the needs to arise first.
Every industry expert I've heard on podcasts, blogs and interviews recommend learning Silverlight first and then gradually moving to WPF which is a huge UI framework.
Silverlight is light and allows you to work on smaller subset of controls and features such that you get your head around this new UI building paradigm based on,
Templating
DataBinding
Styles
Update: 07/2011
I hate to mention this, but in recent times Microsoft has put more focus on HTML5, Javascript and CSS by bringing forward powers of IE 9 and IE 10, as well as the upcoming Windows 8.
More and more developers and CTOs are skeptical about Silverlight as a LOB application platform as the time passes by, we are suspecting Silverlight will be limited to Windows Phone and niche, domain areas like healthcare of graphics related applications rather than a regular LOB app.
As it seems right now, as of summer 2011, the future might look fragmented with more opportunities for pure web technologies (HTML5, JS and CSS) as opposed to a plugin and OS-specific UI technology.
I would start by learning XAML, by reading a few tutorials and playing around with XAMLPad. This will give you a feel for the basics before actually building an app.
I would start with WPF and doing very simple control familiarizaton samples. You goal should be to learn XAML and Binding. So if you just create some basic WPF window apps will bootstrap your learning speed. Then eventually you can move to silverlight. Yeah as other mentioned here Silverlight is a subset of WPF.
Well, it depends on what you are going to be working on. If you are working on client/server, then I would go with WPF. If you are working in an environment where you can guarantee that .Net is installed on all of the machines, then I would go with WPF as well, because you can use what is called an XBAP, which is a WPF application that is run through the browser.
It's really up to you. However, I would state that silverlight is not RTM yet, and WPF is. WPF has a lot of books out on the subject, where silverlight does not. It may be easier to get the whole Zen of WPF by reading a few of those books, and then dive into which ever one you would like to play with.
Just keep in mind that silverlight has a subset of the controls of WPF, a paired down .Net framework, and does not do synchronous calls. As long as you know that up front, you can start learned the core of the whole foundation and tailor your practical experience later on to whichever technology is best for you.
Some tips at Getting started with Silverlight Development