Dynamically loading Business/Validation Rules

Nemisis posted on Friday, March 20, 2009

Hi everyone, we have a system that is up and running using the older 2.0 csla framework. Now the new framework is out, i have got the book and of course rethinking how things can be done.

Our needs are very specific and wonder if csla can handle doing this.

EXAMPLE
We have 2 databases, each database will hold in a table whether particular fields are mandatory or not, how long the strings can be etc etc. Is there a way to create these business/validation rules at runtime for each object.

Each database will contain the same base data for the same objects, for example company. Each company object will have 3 properties Id, Name and Reference.

In Db1 Name maybe aloud to be a maximum of 50 chars, but in Db2 name maybe aloud to be 100 chars and the reference mandatory.

Does anyone know if this sort of functionality is possible using csla? Whether it can be done dynamically at runtime? I would like to create the business rules at runtime, so data binding etc works without additional coding.

This app is run on a website, but we will be expanding to run via web services, windows forms etc.

Thanks in advanced.

JoeFallon1 replied on Friday, March 20, 2009

I do all of this with a single database for my web app and it works very well. I read the metadata from the DB and then use it to enforce all the dynamic rules of the BO at run time. (The BO still has some static rules from design time.) I also use the metadata to draw the page. e.g. show/hide fields from a given user type.

As long as you fetch the metadata from DB1 and only use it on BOs for DB1 it should work the same as mine. I have no idea what happens if you mix up the metadata and BO for different DBs.

Joe

Nemisis replied on Friday, March 20, 2009

Joe, this sounds great and exactly what i want to do, although as you have stated, i am not sure if things get confusing because i want to do it on multiple databases and each database BO rule cannot be shown to another database BO rule.

Is there any chance you can point me in the direction of how to read the meta data and create a simple dynamic BO rule? Or give me a page of an example as i dont mind reading to find out how to do it.

The only other thing i thought i could do was create the BOs for each database at runtime, from a base BO, and create the properties etc at that time as well as the rules? But not sure if this would be a performance nightmare, as sounds it

JoeFallon1 replied on Friday, March 20, 2009

Assuming you can keep the BO -> DB relationship correct then it is best to have your metadata fields match up with your BO properties at design time. I do not like the idea of creating BO properties at run time. They are "fake" and usually live in a dictionary someplace.

I have a root BO that I call a UOW (Unit Of Work - but a better name may be a Use Case Controller as it handles all the interactions for the use case.)

The UOW contains many other objects. So when you create a new UOW you essentially retrieve these other objects during DataPortal_Fetch too.

One of them is a ReadOnly list of metadata rules for the particular type you are working with.

We also define rules in the database which are different kinds of metadata. These rules are also retrieved when the UOW is created. These rules live inside a class which knows how to evaluate them at run time based on the BO data. So this class is fetched into the UOW.

The UOW has a normal rule added to it that calls a method to determine if the metarules are valid or not. This simply forwards the call to the class that has all the rules and passes in the BO for evaluation. It also passes in a string ByRef named ruleDescr which is filled in with any broken rules as they get evaluated. So when the all the rules run the list of issues is made available as part of a normal broken rule. If they all pass then the meta rules are valid.

Joe

 

 

Nemisis replied on Monday, March 23, 2009

Joe, i agree, i dont really want to create BOs for each database and the relationship between BO -> Db is the same for all databases, the only difference being that in some databases a property maybe mandatory, readonly and/or have a different length, so adding the dynamic rules has to be done i think, as in the current version this was a bit of a nightmare to get the UI to handle, when it should really be in the BO itself, especially as in the next version we will be moving to other available UIs.
I think i am just going to have to create a simple BO to start with and go from there, but thanks for your help.

dg78 replied on Thursday, April 02, 2009

Hello Joe,

 

Since many times, you wrote about your Use Case Controller (or Unit Of Work).

I don't know this concept but I think it would be very useful.

 

Is there any chance you post a (small) code example about that ?

 

Always I think a small code is better to understand that many words mostly for non native English language people as me.

 

Thanks in advance.

 

Dominique

JoeFallon1 replied on Friday, April 03, 2009

Dominique,
The idea of a Use Case Controller or a Unit Of Work is actually very simple.

1. It is a normal Root level BO.

2. It typically only has 1 factory method: NewUOW.

3. The factory method accepts whatever parameters are needed for the use case. (PO Number, Invoice Number, UserId, whatever.)

4. In DataPortal_Create you set any Defaults of the UOW and then fetch any child collections or child objects using the parameter(s) passed into the factory method.

5. A call to Save on the UOW will get you to DataPortal.Insert or Update (sometimes I send both methods to the same Sub). There you have control over all child objects and can manipulate them prior to calling save on each of them. Plus you can wrap them all in a transaction if needed.

6. So your screen or web page fetches the UOW and then binds to any objects needed to display that page. But the UOW fetches all of them - not the page. That way if you change UIs, the same UOW will work for the new UI too.

7. The UOW can have validation rules that span the various internal BOs. Make sure that 1 or more records exist for this collection, or check that if this BO has this property set then that other BO has that other property set.

HTH
Joe

rsbaker0 replied on Saturday, April 04, 2009

^^^^

I've basically been doing this without even knowing what it was called. Who knew? :)

We use this is as translation technique from our legacy system, where the old form of the UOW was a single function call that did a BeginTrans... bunch of updates... CommitTrans.

Now we just create an object that has the same properties (or NewUOW factory parameters) as the old function did, and it does the same work in DataPortal_Insert/Update. It's a very straight-forward translation.