I have a class Bank Account to do standard payment senerio. It has a NameOnAccount, AccountNumber, AccountConfirmNumber, and RoutingNumber. The First Case that I had to code used all the fields and was able to add validation for the use case (about 8 rules total).
Now I have a second use case and the use case doesn't require the NameOnAccount or the AccountConfirm. So the validation is about 4 rules total.
I could use inheritance to to add rules on top of rules, but that doesn't seem very flexible. What if I wanted different rules based on user role or runtime context
I could change the actual rules to take into account user role or some other property of the object, but then I would have to write specific rules that can't be reused.
What I think makes sense is to be able to inject the rules or be able to set a property of the object before the rules are added. But they are added when the object is instanciated, so I never get a chance to get into it.
What are some strategies/best practices for handling this situation?
In my past experience I always wrote custom rules in such cases.
Sergey Barskiy
Senior Consultant
office: 678.405.0687 |
mobile: 404.388.1899
Microsoft Worldwide Partner of the Year | Custom
Development Solutions, Technical Innovation
From: ssuing8825
[mailto:cslanet@lhotka.net]
Sent: Friday, May 30, 2008 8:25 AM
To: Sergey Barskiy
Subject: [CSLA .NET] Different Business Rules for Same Class
I have a class Bank Account to do standard payment senerio. It has a
NameOnAccount, AccountNumber, AccountConfirmNumber, and RoutingNumber. The
First Case that I had to code used all the fields and was able to add
validation for the use case (about 8 rules total).
Now I have a second use case and the use case doesn't require the
NameOnAccount or the AccountConfirm. So the validation is about 4 rules total.
I could use inheritance to to add rules on top of rules, but that doesn't
seem very flexible. What if I wanted different rules based on user role or
runtime context
I could change the actual rules to take into account user role or some other
property of the object, but then I would have to write specific rules that
can't be reused.
What I think makes sense is to be able to inject the rules or be able to set
a property of the object before the rules are added. But they are added
when the object is instanciated, so I never get a chance to get into it.
What are some strategies/best practices for handling this situation?
There are indeed 2 use cases here and I can see creating 2 BO. But from flexiblity standpoint it would be nice to compose the BO at runtime vs at design time (at least the rules.). That would give me much more flexibility especially if I had 5 different roles and the validation is different for all of them. I could always change the protection level on the Validatation rules so that I could do that, but wanted to see what others were doing first. To look further, if I had to add a 6th role then I would only have to change the Rules, not add an entirely new BO.
Copyright (c) Marimer LLC