We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you a podcast all about Citrix Workspace, moving to the cloud, and analytics & intelligence. Episode 2 coming soon!Listen Now


Business Rules Implementation

EBatista asked
Medium Priority
Last Modified: 2008-03-17
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 { ??? }
Watch Question

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..


>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
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.


then this will be ok?:

  if Rules.CheckDpoID(value)
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.


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.


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).


Well some rules changes often, others are the same for almost 15 years.
My architecture:

GUI (WinForm)
Domain clasess
Object Persistent Layer (Gentle.NET)
As the above user stated, we can design the application to any extent we want. But depending on lot of factors (time, resources, expenses, criticality) you have to draw a line somewhere. I agree you probably shouldn't name your class as businessrules.cs. We once had a rule engine for one of our applications, where there was a rule engine factory that returns the proper rule engine for the entities etc. Of course, code level rule engine implies your rules don't change often. If you need that level of flexibility, you can even write your own customized rule engine enterpriselibrary application block which stores everything in xml configuration files and gives you a visual data editability. You just need to change the rules in the enterprise library GUI which has already been created for you by Microsoft.. But I'm not sure how complicated, flexible you want to make your application. You could also store your rules in xml files but then you need to manually edit them..  database is extra overhead since you may have to build another app to update rules.. probably xml files are the best.

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts

I would compile some suggestions and get them to you soon..


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


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.
I guess the best "pattern" to follow is keep a tiered approach.  Data layer, business layer, presentation layer.  How strict you need to be regarding this depends on your application platform.  If its thick client then keep ALL business logic out of your presentation layer and use a well designed web service/remoting tier.  that will allow you to always make changes without having to recompile and deploy the presentation layer (keeeping in mind your not changing the interface.)  If its a think client like asp.net then its not so critical that it be another "physical tier" but do indeed keep it a logical tier by keeping logic out of presentation classes (pages, forms, controls).

also try to keep logic in resources that you can edit without recompile like database/xml/config.

as far as the industry goes when business logic gets crazy you should begin looking at a message bus like solution ie Microsoft Biztalk Server.  It allows for amazing business logic construction and change with little/no code.  it creates processes by using BPEL (business process execution language) that basically assembling services.

so this is hardddddddd one to answer because in this case, "it really does just depend."

oh by the way this just came to mind.  another good practice if you dont want another physicall tier to hold logic (web services) then keep all of your logic in seperate assemblies (.dll) that way if you make a logic change your only deploying a single dll instead of an entire install.

good luck.

-gary p.
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.