views:

178

answers:

4

I am looking to do something like this

public class ProductBiz: BizBase<Product> {

public List<String> BrokenRules {get;set;}

// Some kind of data + biz operation implementation

}

public static class ProductBizExtensions{

public ProductBiz Rule1(this ProductBiz prodBiz)
{}
public ProductBiz Rule2(this ProductBiz prodBiz)
{}

public bool ApplyRules (this ProductBiz prodBiz, Func<ProductBiz,bool> ruleset){}
}

Then in client code use it as

productBiz.Rule1().Rule2();
productBiz.Rule2().Rule1();

OR

// create multicasted delegate of type Func<ProductBiz,bool> say rulesetDelegate

productBiz.ApplyRules(rulesetDelegate);

Just wanted to ask before i dive deep and drown.

What are the potential pitfalls with this approach???

Thanks in advance

A: 

Yeah, but it's fairly disturbing way of doing it ...

Noon Silk
why is it disturbing? you can swap out business rules anytime and the client code too...whats wrong?
Perpetualcoder
Well, extension methods are for attaching methods you classes that you don't control. You can't re-implement them on children, and so on. I see no reason to use extension methods on classes you are writing, and 'Business Logic' is better done in your own objects that you can inherit as becomes approach, and needed. Also, 'business logic' is very general.
Noon Silk
Business Operations remain same...logic changes. So if my extension methods are in a separate assembly i can always rip it out and provide a business specific solution.
Perpetualcoder
"Business Operations remain same" ... heh, that's cute, but sadly untrue. Regardless; as Jared says below, all you're doing is putting logic in static methods. It doesn't make a lot of sense, and it's not how it's generally done [of course, there is some "logic" that *does* go in static methods/classes].
Noon Silk
I meant, A Financial Company "Hires" employees, A Security Firm "Hires" employees but "how" they hire employees changes. This is what I was trying to get to. Not trying to argue but trying to find something concrete. If you can provide an example showing a better techniqe where I can change business rules without mucking with BO's, that would be great!
Perpetualcoder
I am trying to avoid dependencies to AOP or DI frameworks and externalize business rules.
Perpetualcoder
Inheritance: `abstract class HiringSystem { public abstract bool Hire (Person p); }` `class SilkyHiringProcess : HiringSystem { ... }`, and so on. That's the OOP model.
Noon Silk
I think you should read this classic article http://thedailywtf.com/Articles/The_Enterprise_Rules_Engine.aspx
Josh
+1  A: 

I'm not sure what you mean by possible. It's certainly possible to write a rules engine in this way and you've demo'd an outline of how to achieve this.

Don't forget that extension methods are just syntactic sugar on top of static methods. Asking if you can do X type of programming with extension methods is no different than asking if you can do X type of programming with static methods. Static methods may not look as nice but they are just as powerful.

JaredPar
+2  A: 

If you're looking at changing the rules at run-time then you might want to consider something more like MEF or similar.

Your solution is fine up until you compile, then it's set and locked, from the sound of your comments you're looking for run-time flexibility.

Timothy Walters
does i have a prod ready release?? i just saw preview on the site. nice idea though
Perpetualcoder
+2  A: 

Look at the implementation of business rules in CSLA http://lhotka.net/ . In that you define a rule w/ a particular signature, and add it into the object's rule store, either at a class level or instance level. The syntax of what you are attempting to do is off-putting, but the method (defining business rules via static methods which are executed at run time) is exactly what CSLA does.

chris.w.mclean