locked
Performance issues using dynamically loaded dlls? RRS feed

  • Question

  • Hi,

     

    I have fairly complex business rules that may vary regarding who is logged on or which underlying system the user is targetting.

     

    I was thinking of using the WF rules stuff outside workflows to get what I want, but this approach is a bit limited (as far as my limited knowledge shows me). So I am leaning at loading business rules dlls, where I can customize everything I need and just load the appropriate dll on demand. An available solution is to just use the same instantiation pattern that Microsoft gives right out of the box (used in membershipprovider, roleprovider etc). Another solution that will be available probably this fall is the new System.AddIn namespace in Orcas. The latter is probably closer to what I need to do.

     

    Does anyone have any experience on using dynamically loaded dlls? Anything I need to know is appreciated, be it performance related, maintenance related or anything.

     

    Oh, I almost forgot: This scenario will be a SOA system with WCF services. Most of the end user access to the system will be through web sites.

     

    Thanks a lot,

     

    Morten

     

    Sunday, May 20, 2007 2:20 PM

Answers

  • Rule engines do not come instead of business logic
    However given that you can create your pieces of business logic as basic building blocks (send email, deduct fee, pay provisions etc.) rule engines allows you to set a routing rules that will determine which pieces should be executed. if order is larger than1000 do email someone if larger that 1000000 sms someone else etc.
    One application where I used a rule engine was when we've built an ordering system for mobile operators - for instance we had a rule engine to find eligible plans for a customer based on his demographics , usage patterns etc

    Arnon
    Friday, June 1, 2007 12:06 PM

All replies

  • Yes, there are performance issues. Loading a DLL at runtime takes some time, depending on its size, number of types, etc. You probably don't want to be doing this sort of thing in a tight loop in a performance critical section of code. Also, be aware that you can't unload a DLL once its been loaded, unless you load it into a separate AppDomain. If you have HUGE DLLs, and not much spare memory, this might cause your windows to start paging memory - but this scenario is unlikely for most desktop and server apps. Small form factors like mobile phones and PDAs may be more influenced by this.

     

    All in all, I think that there are simpler more maintainable solutions. Look at things like the strategy pattern, decorator pattern, and state machine pattern. They are great at handling complex business logic.

    Sunday, May 20, 2007 7:36 PM
  • If you have a lot of business rules and you need high performance, I would be weary of deploying DLLs in runtime (which, by the way, also introduces a security risk)
    There are commercial products like InRule or Ilog Rules as well as open source options like NxBRE

    Arnon
    Sunday, May 20, 2007 10:30 PM
  • Can you give more details regarding the packaging of the rules? For instance, does an assembly contains exactly one rule, multiple, logical grouping?

    We've build a medical acceptance testing system which dynamically loads a different rule set based on the type of actor submitting personal information. We use, as Udi suggested, standard patterns, actually those that Udi mentioned. Great performance as long as you keep an eye on the packaging of your rule sets. Business rule engines bring a whole different level of complexity to your project. If you "think" you need a business rule engine... then the changes are high you actually don't need one. Don't try to solve problems in a domain with technology.
    Tuesday, May 22, 2007 4:06 PM
  • I have a problem seeing how a rule engine can solve the stuff I need.

     

    Let's say I am getting a request for a money transfer from one account to another. Based on the type of request, the origin of the request and the associated partner, the following might happen: The original request will be drawn very simply from the origin account. But then I need some business logic that may or may not split up the transaction amount into smaller fractions and distribute on different account: Provisions are paid (maybe even to multiple recipients), fees are deducted, email receipts are sent, sms receipts may be sent, fees are deducted on SMS receipts etc.

     

    If a rule engine can handle such a type of business logic, I will be very interested to hear about it. I have little experience with this. I have only looked at the Rule Engine in WF, and I couldn't see any place there where I could do this kind of processing in the rule itself (I haven't tried the rule engine within a workflow itself, because I am a little concerned about the performance of a workflow for an OLTP environment.

     

    Any tips are greatly appreciated.

     

    Thanks,

     

    Morten

    Saturday, May 26, 2007 7:08 PM
  • Rule engines do not come instead of business logic
    However given that you can create your pieces of business logic as basic building blocks (send email, deduct fee, pay provisions etc.) rule engines allows you to set a routing rules that will determine which pieces should be executed. if order is larger than1000 do email someone if larger that 1000000 sms someone else etc.
    One application where I used a rule engine was when we've built an ordering system for mobile operators - for instance we had a rule engine to find eligible plans for a customer based on his demographics , usage patterns etc

    Arnon
    Friday, June 1, 2007 12:06 PM