We have lots of project developed using .net 2.0 version if I want to convert those project to WPF then what will be the approach. Please discuss in detail.
to let the migration to WPF easy, be sure that your existing code doesnt contains a high coupling between GUI and your Business layer, if it's the case the most important step is to refactor your existing code, so your GUI code will contains only what's related to GUI.
And after this step the part of your project to migrate will be not the big one, it will concerns only the GUI logic.
When I did this kind of migration from winform to WPF , we spent more time to remove coupling between GUI and other layers than to migrate the GUI layer, due to high coupling betwn GUI and other layers.
Having gone through a similar exercise I'll tell you that it can be done but there are some challenges.
Step1: Just for clarification when we say WPF some people mean Silvelright / web. WPF is not Silverlight so you need to clarify I want to migrate existing applicaitons to WPF thick client applications. Since you stated WPF I am assuming you mean thich client/windows based applications so we'll go that route. (I'll mention SL at the end)
Step 2: Evaluate your projects from the code level for the most part refactoring the code is fairly easy. Since you are migrating from .net 2.0 to .net 4.0 I would really look at how many of your classes are defined, and see what can be refactored or in some isntances completely redesigned. THis leads us directly into step 3.
Step 3: Pick a design pattern. One of the tricky parts is coming to terms with a new design patterns such as MVVM for WPF. More than lilkely you will want to strip out and redesign the entire UI. As a result you will also want to utilize a proper design pattern (MVVM) or some flavor of that. This will also tie back to step two as some of your code will need to change to support your design pattern.
There are a ton of resources online for MVVM as well as UI development. If you are looking for reading materials I would look to WPF 4 unleashed as well as WPF illustrated. Both are good reads to help you get up to speed on the UI components how they work and the proper approach to using them in a project.
Get familar with .net 4 and the use of collections, types and of course the numerous new classes for wpf.
Disclaimer: You can in many instances create a WPF application usign tradition winform layout and practices. Whether this is right or wrong is a matter of opion of the developer. My personal opinion is that yes you can forego learning new design patterns and use a winform approach but you will not gain the full benefit and capabilities of the framework using this approach.
And finally if you are planning to migrate these apps to the web (silverlight) your work will be a little more of a challenge. Silvelright does have a little higer learning curve and there are a few more rules (security, asynchronous calls, web services etc) that must be learned, and followed. I have foudn that in creating a migration that it is easier to migrate from Siverlight to WPF that vice versa. As Microsoft continues to improve Sivelright I think we will get to the point to where the code is interchangeable between the two patterns however right now it's not there.
Conduct a search online but here are a few links to help you get started:
Scott Guthrie (Silverlight) http://weblogs.asp.net/scottgu/default.aspx
Josh Smith (WPF MVVM) http://joshsmithonwpf.wordpress.com/
best of luck
Related
Seeing as how MVVM is being highly regarded as a good system design pattern, I thought I might just jump aboard and give MVVM a shot.
Just a little background about myself before I begin with questions:
I have done a few years of development with ASP.NET Webforms. I have also done a fair bit of development in ASP.NET MVC, which I am quite comfortable with.
Currently, we have a number of "backbone" applications written using ASP.NET MVC 3 which we customize and sell to our clients whenever we're approached. These applications are all meant for internal use, hence plug-ins wouldn't be much of a problem.
The real problem with development is that for large scale business applications with complex business rules, ASP.NET MVC tends to slow us down (writing jQuery / javascript > server side processing > return result, use jQuery to notify > alter view, something along this line).
Then I began looking for answers that will help us improve our time to delivery and also responsiveness (well, we all know how JavaScript is capable of killing us) and my search brought me to Silverlight (we have the time to change, no worries there).
So here comes the questions:
I have come across many Silverlight MVVM samples online, but all of them show applications as simple as interacting with only one Database table. Is MVVM pattern well suited for large applications?
In MVC, I'm used to Dependency Injection from Ninject to pass an implementation of UnitOfWork to my Controller. In all samples I found online, none of them use any form of DI. Is it really unnecessary? Since the idea of MVVM is to decouple, so why not also decouple ViewModel from Model?
I've gone through a book published by Jeremy Likness called Designing Silverlight Business Applications. He used MEF to do the decoupling, which I think doesn't really fit into our application. We do not really need to do "hot-plugging". What's your take on this?
MVVM is all about Commands, Databindings and No Code-behinds. What if I want to interact with UIs that do not expose to commands? (I'm not too sure about this, I'm guessing ListView OnSelectionChange?)
To add to the previous answer:
We are developing a large corporate-wide Silverlight platform and a set of applications using MVVM. Seems to be working pretty well.
We are using DI extensively. Our system is built on top of Prism. Prism contains a large amount of sample applications of various complexity illustrating the use of DI in MVVM.
We use Unity as our IoC container. Prism contains guidance for both MEF and Unity. Unity seems to be a more traditional IoC approach.
In the vast majority of cases using Bindings and Commands covered our needs. For the others we use Expression Triggers and Actions. You can also create custom Triggers/Actions if necessary.
I have no answers for all your answers (never used MEF) but I can tell you my experience:
1- I've been in the development of a quite-large silverlight application and MVVM fits perfect to have a maintainable application. The bigger problems we had because of application size were because of Silverlight, not MVVM 8-)
2- I haven't used it too much but it's useful in many cases. There are several toolkits to use DI with Silverlight like MVVM Light Toolkit:
http://compiledexperience.com/blog/posts/blendable-mvvm-dependency-injection-and-unit-testing
4- For interaction between UIs you can use the Mediator pattern. The same MVVM Light Toolkit has a Messenger to subscribe, send and receive messages and maitain every layer decoupled.
Hope this helps you ;-)
I am going to develop a winform project of considerable size. I am planning to use Entity Framework as ORM tool. Now I am searching for an architecture(MVC/MVP/MVVM etc..) to implement all these. Firstly there are few choices for n-layered architecture for windows forms and most those I get are written prior to EF came into market. I got a framework called Rocket Framework from codeplex(http://rocketframework.codeplex.com)
I have looked around it but am skeptical that it will accommodate a wide range of requirements. If anyone has already discovered the wheel already, please guide me through.
Also if the existing architectures prior EF4 can accommodate it than also I can give it a try.
Ideas please!
Well your choices is influenced by the technology you're using. Some technologies make a certain pattern natural to do and thus if you (and every developer) don't explicitely design and care about this you'll end up with what feels most natural. On WinForms the most natural pattern is MVP. You have your view that you can layout in the designer and your code-behind file becomes the presenter, essentially combining view and presenter in one class (it's a 1:1 relationship anyway). For web applications on the other hand MVC is a natural pattern since your web server already acts as a controller. Finally MVVM is supported very well in WPF, although you could fall towards MVP there as well if you start using the code behind file a lot. But relying on DataBinding instead can make you forget to use the code behind file. A good article I read about this is here. Of course you can realize MVVM with WinForms, read this link for a good example.
From the point of testability MVVM is perceived as the best pattern since your view model (and therefor the behavior of your view) can be tested without an actual GUI. MVP however is easy to understand and realize, doesn't require complex bindings and gives you most control over what is happening (e.g. event suppression).
WinForms applications are mostly developed with MVP pattern. The original MVC is not used very much - only its Model-2 variant (for example ASP.NET MVC) for web applications. MVVM is used primarily with WPF and Silverlight.
Neither of these patterns affects how you use Entity framework - they are not data access related patterns.
After a lot of R&D and extensive study I finally settled here:
https://github.com/geersch/ModelViewPresenter
It is an MVP architecture written by Christophe Geers. It supports all I needed- Architecture for winform, web portability support, Entity Framework. Really nice and easy to use.
Additional reading:
http://www.cerquit.com/blogs/post/MVP-Part-I-e28093-Building-it-from-Scratch.aspx
I have done one full project using WPF, and have (at least) a pretty good grasp of the main concepts, like XAML, Databinding, and MVVM. We did everything "by hand"--we did not use an MVVM framework or third-party tools. All XAML was written by hand as well (no Blend).
The new project I will start in a few weeks is pretty heavy-duty Silverlight, and I'm looking to get up to speed as quickly as possible. However most of the articles I've read on getting started with SL focus on XAML and databinding. Since my introduction to these concepts is still very fresh in my memory, I can certainly understand why these tutorials would spend a lot of time on these subjects--the learning curve can be very steep. However these are concepts that I am already familiar with, and find myself having to wade through a lot of covered ground to learn anything new and compelling.
So what I'm looking for are advice on what I need to learn and understand to go from being a journeyman WPF'er to a journeyman Silverlight'er. This can be in the form of:
General Advice
Key Differences
Rules of Thumb
Resources/Links ("A WPFer's Guide to
Silverlight" would be perfect :)
Major Pitfalls/Things to Watch Out For
Thanks in advance for any insight.
Rob Eisenberg (creator of Caliburn and Caliburn Micro) has a series of blog posts that talks about porting a WPF application to Silverlight. This may give you some insight into some of the framework differences.
Day 1
http://devlicio.us/blogs/rob_eisenberg/archive/2010/03/25/porting-nhprof-from-wpf-to-silverlight-day-1.aspx
Day 2 http://devlicio.us/blogs/rob_eisenberg/archive/2010/03/29/porting-nhprof-from-wpf-to-silverlight-day-2.aspx
Day 3 http://devlicio.us/blogs/rob_eisenberg/archive/2010/03/31/porting-nhprof-from-wpf-to-silverlight-day-3.aspx
Day 4 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/01/porting-nhprof-from-wpf-to-silverlight-day-4.aspx
Day 5 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-5.aspx
Day 6 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-6.aspx
Day 7 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-7.aspx
Day 8 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-8.aspx
Some other thoughts off the top of my head:
Binding defaults to One-Way
No DynamicResource
TabControl is fairly different
No ability to define implicit DataTemplates for types
No CoerceValue in Dependency Properties
Event routing is very basic
No built-in command structure. You have the ICommand interface, and ButtonBase controls have a Command property, though there's no class that implements the ICommand interface.
Missing x:Static, x:Type
All service calls need to be on a different thread than the UI thread. This essentially requires you to learn / implement async programming strategies. See here and here.
As was mentioned, it's a different framework so not all libraries are available to you. Example: there is no XmlDocument - you have to use XElement (which is arguably better, though even so)
The Navigation framework is totally different than WPF. Stay away from it. It will only cause you pain. ;]
Several of the Controls that you find in the core framework in WPF you'll find in the Silverlight Toolkit. Download it, you'll need it.
No built-in Triggers, though can use behaviors / actions provided in the Blend SDK (which essentially gives you the same thing)
If you need to interact with a database, it will have to be through services hosted somewhere, or through COM (which means Silverlight 4 OOB with Elevated Permissions).
I disagree with Kevin in that testing is actually fairly easy and all of the major testing frameworks and mocking frameworks support Silverlight. Where you run into issues is Code Coverage. The Microsoft Testing framework supports Code Coverage (Premium & above) or else you can use dotCover. I believe newer versions of nCover supports Silverlight though I'm not 100% certain. Use StatLight to run your Silverlight tests (regardless of testing framework) from the command line.
If you're not already using an IoC container pick one up. Autofac, Ninject, StructureMap, Unity, MEF. (Another bias of mine ;])
I would highly suggest looking into the available MVVM frameworks. This has cut down a significant portion of the framework code I typically have to write. The frameworks will probably only get you 80% of what you need, though that's 80% you didn't have to write yourself. I'm currently partial to Caliburn Micro, though most of the popular ones will give you what you need.
I'll add more if I think of more. Good luck in your journey!
I've really only done Silverlight for a real app...but one of my co-workers was a big WPF guy, and so I hear some of his gripes.
You're going to probably need to use a WCF service, etc., for asynchronous queries to your service/business layer
You're using a subset of the .NET framework, so you cannot include ANY of your class libraries as a reference, only Silverlight class libraries can be included. However, you can do stuff like having a 'link to existing file' in a silverlight library that links to a file in other libraries...as long as the code still compiles with only the reduced set. This is a bit of a maintenance nightmare, but if you are doing WPF & Silverlight with some of the same code, it will probably save you from a lot of replication. Make sure to make it a link to the file and not a copy of the file, or changes in one won't change the other.
Unit testing your ViewModels will not be as easy. Need to Moq your service and use a Silverlight unit testing project.
Some of the reduced functionality is annoying for WPF veterans.
I think our WPF guy complained about not being able to bind stuff like a CanExecute method as easily on his commands as he was able to do in WPF. He had to call the method directly from the command or something. (I've only gotten a chance to look at MVVM a little so far as I'm now on a different project :(, so not quite sure on that one).
Hope that helps a little.
=======
So i decide to to develop my asp.net site into Silverlight.
I today start to search articles about MVVM pattern which i want use in my Silverlight app, and i am confused :/ It's hart to me understand how works this pattern. I am find 3 frameworks which supports MVVM pattern in Silverlight - Caliburn, MVVM Light Toolkit and GoodLight.
Should i start from own implementation of pattern or use framework?
Is this frameworks only a project solutions in which i can insert my code?
Which framework is the best for novice and which for professional?
I ask for this, cause i must start to rewrite my app from asp.net to Silverlight and i don't know that i can do it first and later (when i understand MVVM pattern and framework) implement this pattern in finished app ? Or from begining rewrite project to MVVM framework?
Going from ASP.NET to Silverlight is likely to require a (nearly) complete rewrite. The usage scenario is quite different. Silverlight is all about providing a client-side like development environment - it makes it so you can write an application the same way you'd write a client-side, desktop application, but execute this within the context of a browser.
This has fairly broad implications on how you'd use and develop your software.
That being said - for frameworks... Personally, I'd recommend getting a good grasp of MVVM first, then choose a framework (if any). MVVM is really a simple architectural design pattern. Once you understand it, the frameworks will make more sense. It's difficult to suggest "pick this framework", since they all add their own, valuable, additions and ways of working.
There are many good sources for learning about MVVM. Personally, (I'm being biased here), I like the intro I wrote (even if it's WPF oriented instead of SL oriented, the concepts are the same). That being said, Jerimiah Morrill's MVVM for Tards is also very good to get a basic understanding of what, exactly, it means when you say MVVM.
Once you understand this, the frameworks will be much more approachable (or avoidable, if you don't want them).
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