Composite UI Application Block and CSLA

William posted on Tuesday, October 10, 2006

Anyone successfully implemented a CSLA based application with CAB? I would like to get advices on best practices and guidelines in using CAB with CSLA. I went through the CAB documentation and lab, but I am still not convinced in CAB and CSLA to design and develop a flexible and well structured Windows Forms application.

Regards,
William

 

ajj3085 replied on Tuesday, October 10, 2006

I'd think they'd mix just fine.  However you build your UI, you still hand off business logic to the business objects.  I'm not convienced that CAB is all that helpful though, but I haven't dug into it in any great detail.

Brent replied on Tuesday, October 10, 2006

I agree that they would mix fine.  I've played with CAB a bit and been to a few CAB training sessions and in my opinion unless you are committed fully to it, it's going to be a pain in the rear.  If you do decide to go with CAB, use the Smart Client Software Factory which will help you create the 100 solution files you're going to need (about one for every form.)

William replied on Tuesday, October 10, 2006

ajj3085 replied on Wednesday, October 11, 2006

Yan,

The pain comes just from using the CAB, and has nothing to do with Csla itself I believe. 

I looked at the cab, and just figuring out where to get started was not simple, to put it mildly. 

Like anything else, you should evaluate the CAB and determine if it is fulfilling some need that is difficult using standard methods.  Don't use it just because you can use some buzzwords.

HTH
Andy

simon_may replied on Wednesday, October 11, 2006

CAB and SCSF are not trivial by any stretch of the imagination. You should think carefully as to what benefits they can provide for you and your app. They are very powerful but still evolving quite quickly. I have been looking at both and have done an evaluation project with CAB and have noticed that concepts can change as more people use it and especially as the reference applications have been developed. This is to be expected so you should not go in thinking this is all finished.

In my opinion CAB is useful if you need a degree of plugability and integration for diverse application modules because there is a lot more work involved than writing a straight forward winforms UI.

I concur with Andy, using CSLA based business logic should present no problems - getting your head around some of the CAB concepts is another matteer altogether. There is some really neat stuff in there: the Object Builder dependency injection support stuff for one.

You should check out the following https://blogs.msdn.com/eugeniop/ links to a series of interviews with Peter Provost a lead in the MS P&P team who is very informative on CAB and SCSF internals and development thoughts

Regards

Simon

William replied on Wednesday, October 11, 2006

enigmativity replied on Monday, November 20, 2006

I've just been hitting a major problem with CSLA & CAB and would love to know if I'm missing something...

CSLA uses shared methods and reflection to do the data access code. CAB uses the concept of service dependency injection to instantiate separate objects that get your data.

By the time CSLA calls your business object code for "DataPortal_Create" (for example) your object is already created. If your object wants to use a CAB service code then you can't have a service that actually creates your object. In fact, if you try to create a nice service object to do all of your data access and object creation then there is no way, other than to modify Rocky's code directly, to get it to be used by CSLA.

Any thoughts?

Bayu replied on Tuesday, November 21, 2006

enigmativity:

I've just been hitting a major problem with CSLA & CAB and would love to know if I'm missing something...

CSLA uses shared methods and reflection to do the data access code. CAB uses the concept of service dependency injection to instantiate separate objects that get your data.

By the time CSLA calls your business object code for "DataPortal_Create" (for example) your object is already created. If your object wants to use a CAB service code then you can't have a service that actually creates your object. In fact, if you try to create a nice service object to do all of your data access and object creation then there is no way, other than to modify Rocky's code directly, to get it to be used by CSLA.

Any thoughts?

You had your views instantiating BOs ??
That does not sound right to me .... the dependency injection system is inteded to ensure the correct 'building' of your views, smartparts, workitems, controllers, etc. regardless of where (in which plug-in module) you define them. I don't think BOs should be included in this as additional dependencies.

I have have my views instantiate Presenters for them, then in the presenter I fetch the BO using the appropriate factory method.

Szymon Kobalczyk wrote an nice series of articles that introduce CAB.See also his blog ... in one of his tutorials he also discusses the Presenter, which is where I based my implementation on.

Bayu

ajj3085 replied on Tuesday, November 21, 2006

I'm backing Bayu's suggestion (since I don't know enough about CAB)..

But nothing should be bypassing the static factory methods to create BOs.  Using reflection to do so defeats the purpose of having them in the first place.  Because BOs can be complicated to 'build' (as in construct, hydrate, etc) we prevent direct creation by creating private constructors and force the use of static factory methods, which can handle properly building an instance of a BO.

lukky replied on Thursday, November 08, 2007

Bayu:

I have have my views instantiate Presenters for them, then in the presenter I fetch the BO using the appropriate factory method.
Bayu

Hi,

I stumbled across this post in search of cues on how to use both CSLA and SCSF.

I understand that the Presenter is a good place to instantiate the BO.

What I don't quite understand yet, probably for lack of a working sample, is how you achieve DataBinding between the BO and the View. Or do you discard that completely ?

Or maybe you implement some DataBinding interface on the Presenter to bind the BO to it instead of the View ?

Or do you simply pass the BO to the View ?

Whatever the answer is, I'm curious to know.

Thanks.

Luc

AAKLebanon replied on Saturday, November 10, 2007

me too, i am curious to know although I instantiate my BO from my WorkItemController instead and I make the databinding also from the WorkItemController because my WorkItemcontroller know about the view (through its interface), so I have implemented in the View the property BindingSource that is defined in the IViewInterface...

csanchez replied on Saturday, December 01, 2007

Hi:

I’ve been playing with Cab & SCSF and CSLA for a while with very good result, although I’m prototyping my system.

What I do is instantiate my BO in the UseCase’s WorkitemController and add it to the WorkItem.Items collection. Then using CAB’s dependency injection [Service Dependency] I create then it in the presenter(s) where I’m going to use it. In each presenter’s view I bind to the BO via a presenter public property. I also instanciate my NameValueLists and ReadOnlyLists in the WorkItemController(and add them to the Items collection) so I can share them in my presenters to fill my combo and list boxes.

Right now I’m mixing WPF and WindowsForms controls in my views and binding them to the same BO. Actually, all my views are in WPF(SCSFContrib), but when I need a grid control (which WPF lacks) I create a WindowsFormsHost in the view,  which encapsulates a Windows.Forms.UserControl which has the grid (DevExpress). That way I can change my view when the WPF Grid control arrives. BTW a tried Xceed and Infragistics WPF grid but had a lot of troubles binding to a my BusinessLists.

In the views I bind to the BO throuth standard WPF DataContext (thou you have to make you presenter implement INotifyPropertyChanged if you want to bind to a presenter property and get updates) and use the standard BindingSource in the Windows.Forms UserControl’s grid.

I’m not working in the computer where I have the code but I could post it if you’re interested.

Regard, Christian.

Brent replied on Wednesday, October 11, 2006

That's right.  Sorry I wasn't clearer.  The pain comes from CAB, not CSLA.  CAB is strictly UI and will work fine with CSLA.

The pain with CAB is that it's a lot of work and rework to get organized.  I actually tried CAB before SCSF was released but gave up because the learning curve was high and the time it took to create a single module was great.  SCSF relieves some of the pain in that it creates the modules and dependent projects for you.  What SCSF also does is show you how much work it really is to use CAB for your UI.

My point about the commitment is this:  I have little or no doubt that if you spent some time leaning the ins and outs of CAB, and you had an application or enterprise of applications that could really make use it, and that the benefit you might gain would offset the costs of all the time it would take to use it, that it would be really great.

I can't tell you whether you should go with CAB for your UI framework (whether you use CSLA isn't really an issue here.)  I will say this.  My company is a perfect candidate for CAB.  We have around 20 small internal applications and 3 major external applications that almost all work together in some fashion.  We are currently rewriting all of these applications in .NET 2.0 with CSLA.  However, getting 6 developers up to speed using CAB together to create the 'plug-in' architecture would cost us too much time and money.  It's very possible that we may regret it at some point in the future but the nail in the coffin is that MS could drop it at any time when one of their teams comes up with the 'next best thing'.

As for other frameworks; I really cannot say because I don't have experience with any of them.

No offence to any of the CAB folks out there, this was just my experience.

 

Bayu replied on Tuesday, November 21, 2006

William:

Anyone successfully implemented a CSLA based application with CAB? I would like to get advices on best practices and guidelines in using CAB with CSLA. I went through the CAB documentation and lab, but I am still not convinced in CAB and CSLA to design and develop a flexible and well structured Windows Forms application.

Hey William,

I have succesfully implemented apps based on CAB + CSLA. In my opinion they form a winning team together.

Many people seem to think you would need to 'merge' the two frameworks, but that is exactly what you should not do.
- CSLA is a business objects framework, it provides validation, authorization (and if you wish also authentication), business logic, etc. In addition it allows her BOs to be visualized and maintained easily by supporting databinding and errorproviders.
- CAB us exclusively about UI logic, targeted at flexibility and it also strongly promotes view reuse.

Just like you model CSLA's BOs after use cases, so would you with CABs WorkItems. A single WorkItem can manage multiple views in order to fullfill the designated use case. In addition, your workitems can remain agnostic to rendering specific details as these go into your controllers/presenters (what's in a name ...). Then, on top of that: you can put higher level view-logic in your controllers and the actual low-level rendering logic in your views. This allows one view to be reused by different controllers and also one controller to be attached to different views. Highly dynamic UIs, low maintenance costs and heavy reuse could thus be achieved.

There is a strong learning curve associated to getting up-to-speed with CAB indeed. Personally, I feel I got return on investment already after my first app. By having a powerful tool as CAB in your toolkit that can handle really complex UIs, I have never been tempted to take the wrong path of implementing UI-specific details in my BOs. On this forum already, many people want to get their BOs to communicate to each other, e.g. using Petar's observer pattern as implemented in ActiveObjects. But more often than not, the desired communication is just for UI requirements since one view needs to be synchronized with another. With CAB you would have the EventBroker and State frameworks that preclude moving UI logic in your BOs.

As you probably noticed I am strongly in facour of using CAB, despite the learning curve. I did not find it too hard actually, as most of it made sense to me.

If you need further details, I would gladly be of assistance.

Kind regards,
Bayu