Hi all,
I have a scenario that I imagine comes up quite often, but I'm unsure what the best way is to resolve it.
I've written a core library in CSLA that is used for maintaining application security. Several other CSLA apps are now being prototyped that use this security library.
These libraries allow for the creation / maintenance of an application user, and the applications themselves allow for creation of a user as well as other functionality using this library. The individual apps show different permutations of the different security BOs data that is read from / written to the CSLA objects.
After that lead-in, here's my question:
I want to bind my objects to the application screens, but since each of the screens has slightly different permutations of the data, I can't use a DetailsView (web apps here) since only one object can be bound to these controls. In other words, the user apps have screens that want to treat combinations of two or three different BOs as a single entity on a screen, ie creating a user along with certain related properties that aren't in a single User BO.
Guess my most obvious options would be:
1> 'Wrap' each of the business objects in a composite one and bind that to the controls. From reading the board, I suspect that this might be the recommended action, but in this scenario creating many different similar but different read/write CSLA objects isn't necessarily desirable. both from a productivity and maintenance standpoint.
2> Programatically read / write from the form editors to the data source as needed (basically getting rid of built-in binding functionality.
Anyone have any insight as to what a 'best practice' might be for this? Seems common enough, but first time around the block for us with CSLA. Using VS2005 and CSLA3.x
TIA,
Glenn
Thanks for the feedback. I read the thread and understand what it's driving at I think.
Here's a slightly different phrasing of my issue that might drive home the point a little more clearly.
I have application-specific scenarios that use behaviors clearly defined in core libraries. These scenarios may involve a *composite* of different behaviors. In my opinion, the core libraries shouldn't attempt to account for every scenario a user application might dream up.
In a simplified scenario, I have a User class that handles the creation and management of a new User. There also exists a Membership class that handles extended information about a User (using an ASP.NET paradigm here). Each of these classes is complete and functional.
If one was to create a page where one wanted to utilize management of a User *and* his Membership and modify / save this information together, what might be the suggested approach? Binding to two CSLADataSources isn't possible using the 'view' collection of web controls in 2.0+. The binding mechanism isn't smart enough to 'walk' the relationship between the two classes. Using a DetailsView in this case would be great but the single-binding limitation doesn't allow for it.
Would one create a composite business class using using the relevant libraries and bind to that single class? Example appreciated for that approach.
I understand the concept of isolating behaviors, but am trying to avoid adding a number of very similar business objects to suit the needs of individual UI screens, especially if they involve changes to core libraries.
Copyright (c) Marimer LLC