EBatista
asked on
Business Rules Implementation
Hi, how is the best way to implement business rules for my domain classes?
I know in the "set" part of a property i can use Regular Expressions and alike, but that is not the point, my point is if it could be better encapsulating business rules in clasess created for this purposes or should i mix the rules within the domain objects.
Putting it short and simple, in the example bellow i want to be sure that the variable departmentID is allways a 5 digits number:
public class Employee:Person
{
private int departmentID;
public int DepartmentID
{
get { return departmentID; }
set { ??? }
}
}
I know in the "set" part of a property i can use Regular Expressions and alike, but that is not the point, my point is if it could be better encapsulating business rules in clasess created for this purposes or should i mix the rules within the domain objects.
Putting it short and simple, in the example bellow i want to be sure that the variable departmentID is allways a 5 digits number:
public class Employee:Person
{
private int departmentID;
public int DepartmentID
{
get { return departmentID; }
set { ??? }
}
}
I think this is the best place to enforce that rule... this way you can always be sure there will never be an employee class with a department ID other than 5 digits.. if you put this rule somewhere else, may be there is a hack.. also, your business entity (employee) should know what data it can contain.. but something like creating an employee class criteria (may be you have Manager entity) should lie in your business manager or something like that... this is my 10 cents..
ASKER
>I think this is the best place to enforce that rule
you meant the rule hardcoded in the set part or in a separate class
thanks for your comments prajeebkumar
you meant the rule hardcoded in the set part or in a separate class
thanks for your comments prajeebkumar
Have a class which says rule.cs or bizRules.cs or something.. you can have all your business rules for biz entities defined there.. these rules could be reused by many entities.. say Manager and Employee entity could have the same rule of 5 digits dept ID, you don't have to code it twice..hope that makes sense.
** this is of course if you have many rules and many entities.... otherwise, you can hard code it also, if not reused... it can be a static class.
ASKER
then this will be ok?:
set
{
if Rules.CheckDpoID(value)
{
departmentID=value;
}
else
//notify
}
set
{
if Rules.CheckDpoID(value)
{
departmentID=value;
}
else
//notify
}
I think thats right on the money!!
It really depends on a number of things...
If you where using web services I would place as many of the business rules as I could in an XML schema (fyi xml schemas have facets that use regular expressions, lengths ect). I would then use a custom soap extension to validate the input before it was even serialized and called the webmethod. Since you'd need an xml schema to generate the wsdl this is hardly any extra work.
If you dont expect these rules to change ever or very often then I would implement them via code. However if you expect changes could happen at any time perhaps you should keep these rules in a database or xml file.
If this is a multi-tiered platform make sure you keep all of the rules away from the user tier. If changes are made it will have no impact on that part of the application and you wont need to re-deploy which is a cost in of itself.
I would not advise making a class called "BusinessRules". It seems to work against OOP principals and would become a dumping ground for business rules with no clear autonomy.
-gary p.
If you where using web services I would place as many of the business rules as I could in an XML schema (fyi xml schemas have facets that use regular expressions, lengths ect). I would then use a custom soap extension to validate the input before it was even serialized and called the webmethod. Since you'd need an xml schema to generate the wsdl this is hardly any extra work.
If you dont expect these rules to change ever or very often then I would implement them via code. However if you expect changes could happen at any time perhaps you should keep these rules in a database or xml file.
If this is a multi-tiered platform make sure you keep all of the rules away from the user tier. If changes are made it will have no impact on that part of the application and you wont need to re-deploy which is a cost in of itself.
I would not advise making a class called "BusinessRules". It seems to work against OOP principals and would become a dumping ground for business rules with no clear autonomy.
-gary p.
ASKER
hi devsolns, thanks for replaying, i agree with you that putting the business logic in the user tier is bad design.
Now, if you does not support making a class called "BusinessRules", then which could be the best approach to apply business rules that fulfill OOP principles?.
This is for a multi-tiered system.
Now, if you does not support making a class called "BusinessRules", then which could be the best approach to apply business rules that fulfill OOP principles?.
This is for a multi-tiered system.
EBatista,
How often do you expect these rules to change?
What cost is associated with this change (typically much more expensive given the size of an organization and how critical the application is)?
How do you access your middle tier? (Web services, .NET Remoting or else).
How often do you expect these rules to change?
What cost is associated with this change (typically much more expensive given the size of an organization and how critical the application is)?
How do you access your middle tier? (Web services, .NET Remoting or else).
ASKER
Well some rules changes often, others are the same for almost 15 years.
My architecture:
GUI (WinForm)
Domain clasess
Object Persistent Layer (Gentle.NET)
Database
My architecture:
GUI (WinForm)
Domain clasess
Object Persistent Layer (Gentle.NET)
Database
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I would compile some suggestions and get them to you soon..
ASKER
ok thanks
Ok real quick, what sort of "business rules" are you talking about.
The your first post it looks like your are validating input for proper format. So can the extent of your rules validation be for input formats/ranges and other facets or does your rules validation need to extend to deeper logic like such:
if(balance <= 0)
{
//do this
}
else if(balance > 0 && balance < 10000)
{
//do this
}
...
The your first post it looks like your are validating input for proper format. So can the extent of your rules validation be for input formats/ranges and other facets or does your rules validation need to extend to deeper logic like such:
if(balance <= 0)
{
//do this
}
else if(balance > 0 && balance < 10000)
{
//do this
}
...
ASKER
yes you are right, the rules can be more complex than the one i posted here, that was just for simplicity. My goal is to apply the business rules following best practices. I wonder if there exist any known pattern to implement business rules.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.