Is it possible to share viewmodels across platforms - WPF/Silverlight? I started down the path of putting my VMs in a separate assembly and soon came to ICommand - which then led me to ask this question? Is this possible, and if so is it good to do so? We have a possibility in the future of having a client application for WPF and Silverlight, so I would like to not have to duplicate VMs for both.
You can potentially do this using the Portable Library Tools CTP. This allows you to target the full framework as well as Silverlight in a single library project.
Otherwise, it is possible, sort of. You still need two separate projects (for practical purposes), but can typically use a single source file. Have each project using the same source files keeps the reuse in place - but does require manual synchronization of the files. You can also add platform-specific functionality easily in this case via partial classes or defines, which does help to keep some of the workarounds for missing Silverlight functionality easy to maintain.
[Almost] whatever is possible in Silverlight, is possible in WPF, too. So if you have a VM working in Silverlight, it will [mostly] work with WPF.
From the other point of view, WPF offers richer possibilities, so you might want to use them in your WPF part of code. You can use the usual #ifdef Silverlight-like tricks.
Also, this question might be useful.
Related
I have been migrating from Windows Forms to WPF and am trying to utilize Prism to meet the requirement that the application be plug-in oriented.
My problem is that there is seemingly no support for it. I have also heard that it is extremely leaky in some cases. Being I am developing an enterprise application, this is unacceptable.
If this is the case, and it is a bad idea to start using Prism, is there any alternatives to make a composite application? Solely using MEF is all I can think of.
With Prism you have the option to use Unity and/or MEF as the IoC/DI framework....it's also quite extensible...so you can plugin different IoC containers if you wish.
Some of the problems with leaks can usually come down to not using WPF in a certain way e.g. need to use Weak delegates / Weak event patterns, etc.
You could roll your own plug-in framework using MEF, but you'll probably need to re-invent some of the things Prism already does for you e.g. an EventAggregator, etc.
You could pick an alternative framework, they all have their strengths and weaknesses.
Alternatives to Prism + MEF for modular MVVM apps
There's another Microsoft technology that is geared to supporting plug-ins namely, System.AddIn/Managed Add-in Framework (MAF)....but you have to put in a bit more scaffolding.
http://www.matthidinger.com/archive/2008/10/12/managed-addin-framework-system.addin-with-wpf.aspx
Someone has come up with a framework that uses MEF here:
http://www.codeproject.com/Articles/43625/Building-an-Extensible-Application-with-MEF-WPF-an
If you want to look at an Enterprise size project with their own very plugable/modular architecture then look at SharpDevelop for inspiration.
http://www.icsharpcode.net/OpenSource/SD/
....and it's not beyond the bounds of possibility, if you really want, to combine the best bits from several frameworks.
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.
I have a WPF application (KaleidoscopeApplication) organized as follows:
Solution (6 projects)
Cryptography (DLL)
Rfid (DLL)
KaleidoscopeApplication (buildable "startup project")
Basically, KaleidoscopeApplication contains a bunch of resources (sounds, images, etc) and your standard WPF junk (App.xaml, App.xaml.cs, other xaml and code).
I need to create a new application that is very similar to Kaleidoscope, but I'm not sure of the best way to organize. This new app will need access to much of the same code and resources as Kaleidoscope. Preferably, I would like to create a new project in the solution, then simply use the "set as startup project" to pick which app I want to build. However, will I be able to access (share) the Resources folder of Kaleidoscope?
I know I will be able to access much of the code if I simply add a reference to the project and include a "using Kaleidoscope". But the resources I'm not so sure about.
Is this the right way to organize or am I asking for trouble in the future?
Thanks in advance!
The recommended solution in this case would be to refactor the resources and any common required code into a separate Assembly that both UI applications could use. You will probably need to do some manual tweaking to make sure everything is exposed the way you need it to be, but it'll make things cleaner in the long run.
I agree with Dan about this. You definitely need a common type of project to put all those shared classes and resources, and one for your start up. From there, you can easily add new projects by following the same kind of pattern of separation of concerns.
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...
We are evaluating the use of WPF for an upcoming project. We plan to "commercialize" some of our internal tools and could really use some of the effects WPF offers. We also like the idea of the design layer and code layers being independent to allow concurrent work.
Where can I find a simple UI built with WPF (XAML) that I can pull apart?
What is the workflow if the designer is creating the UI and the developers are coding. What does the design staff give the developers (.XAML files? an assembly?)
From Microsoft.
An open source app with relatively simple ui that is well designed is crack.net. I used it to finally understand mvvm.
As for design workflow, that's a harder question to answer for you. You need to figure out what will work for you and your designers. They can work within the same .proj file as your developers and that's very conveinient. But you may want to separate those assemblies for management sake.
As far as workflow goes.
I had worked in a team where we had a dedicated UI designer. Though he had a degree in CS he said that using Blend distracts too much from the UI design. So he still was doing mock-ups and a developer was translating that in Blend+VS+manual XAML tweaks.
Also, despite what is claimed, Blend is most useful as an example-snippet editor to better understand XAML.
On my current WPF project I use Kaxaml mostly, since WPF editor in my installation of VS is painfully slow and in-stable.
The idea is that your designer will produce you XAML and developer will simply add code to that - didn't work for us. And honestly, I don't see how that can work at all. Since there are still many things in UI that need to be tweaked for the presentation layer.
Also, any UI technology can be isolated in a well designed system. And I don't really see any advantages of WPF at that. Especially that MS promotes data-binding so eagerly.