Business rules for collections

rossl123 posted on Wednesday, August 22, 2007

Can anyone advise me how I would implement rules based validation of a collection. I am working with a particular collection of objects at the moment that has a few interesting properties that I would like to support, but I don't see a way of doing so with CSLA. Maybe I have fallen a bit behind the times with my version 1 implementation?

As an example of one of my problems consider a collection that has a minimum or maximum count condition, or a dynamic member type rule such as 'member must be of type...'. Would it be easy to implement properties similar to IsValid, or methods such as Validate() for BusinessBase objects, for a BusinessCollectionBase object? Would I have to implement my own subtype to do it?

Cheers
Ross

RockfordLhotka replied on Thursday, August 23, 2007

This topic has been discussed a few times.

Data binding has no infrastructure for business rules on a collection, so there's no supported way to display any broken collection rules to the user. The intent is that rules will exists on objects in the collection, or on the object containing the collection.

Even something like "member must be of type..." has no data binding analog. The item in question must tell data binding whether it is happy or not - it really isn't the job of the collection. Additionally, in .NET 2.0 (and really in CSLA 1.x) collections are strongly typed, so this shouldn't be able to happen to start with.

If you really do have collection-level rules, I'd suggest having an editable root object that contains the collection. Then the parent form can be bound to that root object, and it can implement rules that run against the collection to do these checks. That way you have a mechanism by which you can bind properties of that parent object to the UI and display issues to the user as they occur.

Miroslav Galajda replied on Monday, June 20, 2011

Hi, I need to solve similar problem, but I'll describe it in more detail.

You have most of the time the following type of objects (at least me):

MyRoot
|
|--- IdProperty: int
|
|--- NameProperty: string
|
|--- CodeListTypeProperty: CodeListType

IdProperty and NameProperty are a simple properties

CodeListTypeProperty is a complex property of type CodeListType which is concrete type of business object for representing current value from concrete code list. And the values to choose from for editing depends on property for example NameProperty of MyRoot object.

What you have to do to be able edit that CodeListTypeProperty?

1. Create CodeListTypeList class for holding that list of CodeListType objects

2. Add this list to the form as a datasource binding to for example ComboBox

3. Connect SelectedValue property of ComboBox datasource to CodeListTypeProperty

Finally what I want is to show filtered list of values for CodeListTypeProperty while editing MyRoot. As I said above I need to show only certain values to user. The values that are dependent on NameProperty.

How to deal with this type of requirement?

JonnyBee replied on Wednesday, June 22, 2011

In the CSLA style (business object thinking) you should NOT have multiple objects owning the same instance.

Rocky describes this in the new CSLA 4 - 02 Objects ebook with Containment or Using Relationships.

So, I'd prefer to have:

1: MyRoot should have a data value property for the selected objects "key".

2. A CodeList that hold the possible items.

3 Your form need s at least 2 binding sources - one for the items in the combobox and one for MyRoot

4. The UI should hold a "FilteredBindingList" of CodeList to bind to the ComboBox as available items.

the filtered list may be used to set a filter and make only a subset of items from the VodeList available in the ComboBox.

Read DataBinding FAQ on Comboc DisplayMemer and ValueMember.

The value in ValueMember will typically be writtten to you BO by DataBiinding the SelectedValue to yor <bo>.DataValueProperty.

Miroslav Galajda replied on Wednesday, June 22, 2011

This actually how I've done it and there is also the problem what I see.

You put "FilteredBindingList" as binding source for ComboBox but you have to put the logic to the UI, that filtering condition depends on MyRoot.

This is what I'm trying to solve. That's why I'm asking here how to encapsulate that logic, so that I could use that dependency with every use of MyRoot object.

This has to be by someone already solved. This is very practical thing.

That's why I asked here for about business rules on collections.

Thanks.

Miroslav Galajda replied on Thursday, June 23, 2011

Any suggestions, please?

What I'm trying to discover, is how to maintain dependency between property of one object and a collection of another object.

For example dependency between property P1 of business object A and a collection C, which is used as list of valid values for property P2 of business object A where list of valid values depends on the value of P1. So in short, P1 influences the list of values in C which is the list of valid values for P2.

Thanks