This is more of a conceptual question about where to put a custom validation rule in my business object design. I have a GeneralLedgerTransaction Root object with GeneralLedgerTransactionItem children. The root object has fields like "Transaction Date" and "Source of Transaction". The child object has fields like "Debit Amount", "Credit Amount", and "Chart of Account ID".
The validation rule I need to make will validate that a transaction is balanced (sum of item debits == sum of item credits). My initial design put this validation rule in the Transaction object and I call 2 methods on the child list to get the sum of the debits and sum of credits for comparison. Since the instance of the child list on the Transaction object will never call "PropertyHasChanged()", associating the rule to that property will never cause the rule to evaluate, correct? (Without introducing manual calls to ValidationRules.CheckRules() of course)
In my head I am thinking of possible ways to design this:
1. Keep the rule at the Transaction object level, fire an event from ListChanged of the child list, handle the event on Transaction and manually call ValidationRules.CheckRules. I guess I'd have to look at how the list was changed to figure out when to validate the object since reading data from a database "should" assume the data is valid initially and would be overkill to call CheckRule for each item being read into the transaction.
2. Put the validation rule at the Item level, hook it up to the Debit and Credit properties, and loop through the list of items to check if the transaction balances.
...
Any suggestions? Thanks in advance.
I'd probably keep it at the Transaction level - that's where it's relevant.
As for your "ListChanged" thoughts, you may already be OK. Typically, in your fetch routines, you turn off the firing of ListChanged events - right? So the rule wouldn't get tripped on a DB load.
- Scott
Like Scott, my initial reaction to this is that an item cannot be out of balance, it will almost allways have a net non zero credit or debit amount. Only a transaction can be out of balance so, conceptually, the validation rule belongs there.
Incidentally, I have often pondered a question on general ledger systems. Why do we have a credit and debit amount rather than one amount field with positive and negative values? The last GL system I worked on I just had the one field and all the calculation algorithms seem to be much simpler.
Regards,
Patrick (Alias FatPigeon)
Yes, a debit would be an amount of one sign (i.e. plus or minus), and a credit would be an amount of the other.
But in general people were interested in how an account total was arrived at so a list of account entries with the effect on the account balance (i.e. did it add or subtract) was what was required.
Patrick
Copyright (c) Marimer LLC