views:

1622

answers:

4

I'm three weeks into designing a Silverlight 3 LOB application and I've decided to go with Entity Framework, RIA Services, and the MVVM pattern.

Now I'm looking into all the glue. I'm checking into behaviors, ICommand, dependancy properties, IoC, etc.

There are a number of frameworks for Silverlight as of this writing.

Silverlight.FX
Silverstone
CSLA for Silverlight
Prism
Caliburn

Are these necessary?
Do you have experience with any of these frameworks?
Are these frameworks still applicable for Silverlight 3?
What are the pros and cons of work with any of these frameworks.

To be totally honest, I'm not all that interested in CSLA since we don't use it today but I included it for completeness.

+1  A: 

I don't have any experience with those frameworks, but based just on YAGNI and the newness of Silverlight 3 and RIA Services, I would just stick with Silverlight 3 and RIA Services until you can prove that you have a need for an additional framework.

I would guess (pure speculation) that the new Silverlight 3 features, together with .NET RIA Services, address many of the same Silverlight shortcomings that those frameworks address.

Brad Tutterow
Part of me agrees and the other part wants something a little simplier. Now that I'm getting my head around MVVM, RIA Services, and Silverlight 3 I can't help but feel something is missing but I don't have a full enough understanding to know what that is. This question was more for me to figure out what that "something" is.
Robert Kozak
+2  A: 

One of the things missing still (that is important for MVVM) is commanding. So you will be rolling at least a part of what the framework provides yourself.

I personally don't use any 3rd party framework, but do use an company internal framework that provides me with commanding and has base classes for the ViewModel part of MVVM.

Graeme Bradbury
Commanding is something I know I definitely need.
Robert Kozak
To be honest what i'd do is take a look at the opensource frameworks and take the commanding that is necessary and then add in the other bits as you find you need them.
Graeme Bradbury
Thats actually what I was thinking unless someone here told me that X framework was essential.
Robert Kozak
+1  A: 

I've certainly got a personal bias, based on what I do at work but features I find super useful in any Silverlight project...

  1. Data
  2. Authentication/Security
  3. Triggers/Actions (to keep most of your views declarative)
  4. Behaviors (to encapsulate view functionality into reusable components you can attach to controls)
  5. View Model/MVVM (to separate view from code)
  6. Simple IoC - to get dependencies injected into your view models
  7. Effects, and transitions

If your app is complex/has multiple screens... 8. Navigation and possibly some MVC

1, and 2 - We're hoping to address with .NET RIA Services.

The others, I am trying to provide an implementation via Silverlight.FX... initially as an implementation people can use as-is or as a starting point, and to over time drive them into the platform/SDK.

As far as commanding itself goes, its certainly useful, but not essential in my opinion, if you've got the basic functionality of binding and ability to stitch together events to vanilla methods via actions.

NikhilK
+2  A: 

I like Nikhil's Silverlight.FX as it includes commanding, mvvm and some "fun" items like a mousewheel scrolling behavior. Prism is pretty good too and I think its event publish / subscribe system is more powerful than Silverlight.FX's commanding. Overall I find Prism a bit cumbersome (and not totally relevant if you planning to build a SL3 navigation app). Ninject is my current favorite for DI.

James Cadd
You really think that Prism is more cumbersome? Ninject is very popular but unity looked small and simple. How big is the resulting SilverLight.fx assembly? and the Ninject Assembly?
Robert Kozak
Prism just feels more heavy to me because its not easy to buy into part of the system. I have a project now that could really use the eventing system, but in order to use that you have to use their DI framework (to get an eventAggregator). Nikhil's solution is nice because you can use the commands with very little overhead. To be honest though that's really a small knock on Prism; it's a powerful framework if you've got a large app you're working on. My app is smaller so I prefer lightweight, easy to digest frameworks. Not sure about dll size - download 'em!
James Cadd