Prism 2 and CSLA

greengumby posted on Friday, May 22, 2009

Hi,

Does anyone have any advice or have seen sample apps of how to integrate CSLA with Prism 2 for a large Silverlight Application.

Many Thanks

Jeremy

triplea replied on Friday, May 22, 2009

The only place I found some reference on this was here: http://www.codingandcoffee.com/

But the example being build is using Prism 1 and the blog has gone a bit quite. Also (since its Prism 1) its for WPF and not SL. But I used it as a statring point and got a lot from it.

Jack replied on Friday, May 22, 2009

Jeremy,

I am having success - it is going slowly but I believe/hope that I am almost through most of the technical challenges.  I am quite happy with how it looks like it will work out but it has been a tough learning curve.  CSLA + XAML + Silverlight + CAL + CodeGen is a lot to start with (no prior knowledge before Nov) and a huge jump from a simple winforms application.

Also going from MDI and child windows to a single UI page has been challenging.

I have tackled my bigger more complex UseCases first which didn't help either but taught me a lot.  I really struggled with the concept of getting all my data in the parent and then pushing it out to the children/grandchildren and having the children/grandchildren as independent injectable views.  It was hard to wrap my head around lazyloading certain data vs. retrieving the data and then passing it out to an injected view when it is created on demand (say open an infrequently used tab object).

That so much in Silverlight is async is also a bit of a mind warp but it is also really cool.  I have some windows that open like data portals with each piece retrieving and spinning up on its own.  It looks really cool to see it all arrive to the screen in chunks.

So far I have done the following:

a single CSLADataProvider for each view
a single presenter for each view
use the CSLADataProvider as my model

All views created with Dependency Injection.

I create the presenter/view, kick off the data retrieval or set the Model.objectInstance, drop it into a region or content holder, and that is it.

I've only done one level of regions off a shell and used a single 3rd party popup window control for details although some of my details windows are composite views and that is where I used the ContentControls.  I do plan on expanding that later so just about everything is a region.  I haven't really experimented too much with toggling back & forth between to views in the same region (switching core pages) and optimizing that experience.  I am caching my BO's but recreating views a lot.  Not an issue at the moment but I can likely improve on that.

I would say that leanring and staring to use Interfaces vs. Inheritance was the biggest help.  Without Interfaces the whole disconnected / injected model doesn't work.

Simple one BO/View are fairly straightforward but it gets much harder with complex UI.

When I have a child view I set the CSLADataProvider to ManageLifetime = false and I either retrieve data on demand or I push the data from the parent into the ObjectInstance after creating my presenter.

One big hurdle was with updates and EditLevel and keeping that in sync.  The end result was a I tied a single managerBO to a single dataprovider on a MasterView and used that to do all the DataPortal updates.  On any save, because the data gets auto-cloned, you have to reset all the child DataProvider.objectInstance.

What would be nice is a concept of a parent/child CSLA DataProvider that know how to re-sync the objectinstance so that the EditLevels are all in sync.  I basically use a controller object to manage the interactions between the masterView and the childViews and when I instantiate a new view I link it to the masterDataProvider's Data_Saved event so I know to refresh the view's data after a save.

I sometimes wonder if it would just be easier to have a single view with multiple dataProviders but I am really liking the separation of views.  Especially since I'm new to XAML and Blend I can keep each piece simple.

I'm not doing too much with the unitTesting (which I should) but as a maintenance piece I think it will be awesome to be able to test without the UI.

Anyhow those are some rambling thoughts - I'm sure I could do things more elegantly and I'll change and refactor as things make more sense but I do think they work fairly well together and as more people play with both and ask for updates it should get better.

I'll also add that my inability to generate design time data is killing me.  I'm having to wire up a lot of stuff just to see what its going to look like and then update the XAML. 

jack