locked
Custom business rules in Lightswitch-- how are you doing them? RRS feed

  • General discussion

  • I'm trying to figure out how to write a dll with some custom business rules in it that I can use with my LS server application (it uses the LS HTML client.)

     I can do this in a desktop application simply by copying the dll into a known directory and using reflection to load the assembly with a relative path, querying for the agreed-upon interfaces, etc, and going from there.

    But I'm not sure how to do it in a lightswitch app?  For instance, it's all well and good if I drop my dll into a directory, but when I push things to Azure loading it using a relative path...will that still work?  I'm not sure, and wondered how other people approach this sort of thing in LS.

    I should point out that the idea is to have a 'common' LS app for the customers, with the business rules slightly different for each-- thus the dll concept.  I'm not sure I'd want an actual reference to the dll in the project, since it will be different for each customer. 

    Thanks for any tips, links or suggestions.



    Saturday, October 25, 2014 8:49 PM

All replies

  • Hey Jim,

    Check this out; it may be a fit for what you want to do?


    Ian Mac

    Sunday, October 26, 2014 10:43 AM
  • Thanks Ian.  App-stitch is definitely on the list of things to investigate, but I was thinking about things like security checks, and other items that app-stitch doesn't cover;  so that, for instance if the customer decides that role XYZ can only see certain rows in an Inventory (or Orders, or...) table we can drop in a dll with those rules in it.
    Sunday, October 26, 2014 3:20 PM
  • Excellent question Jim.

    AppStich is also on my list to investigate still, especially when it comes to providing the ability for end users to author their own business rules using a point and click type environment.

    I have the same requirement as you in a LS project that I''ve just started on where the same system needs to be used by multiple clients where each client would have their own client-specific business rules added. These could be simple one line business rules or complex modules with hundreds or thousands of lines of code. I would be implementing the custom business logic for all clients - I do not let them do that. 

    I also have a series of "manager" classes that are included inside the LS server project and are mostly utilised by the Web API controller classes to contain generic business logic that sits between the Web API method and the LS ServerApplicationContext.

    I've not done this as yet, but here is what I plan:

    1. Identify all the points in the application where custom business logic needs to be executed. Some of this will be in the LS save pipeline and some of this will be in the generic manager classes mentioned above.

    2. Create an external class library (to be confirmed whether this should be in an external class library or inside the LS server project, but my gut feel at this point is to keep it separate) to contain a series of interfaces to match all of the interaction points identified in 1 above.

    3. Develop each client-specific business rule library as a separate class library, basically implementing the interfaces contained in the class library defined in 2 above. There might have to be a "generic" implementation with empty stubs for each method that does not do anything and becomes the default business rule library.

    4. Use a 3rd party dependency injection framework (e.g. Simple Injector) to instantiate and inject the required client specific business rule library from 3 above (or the generic stubs only one) during run-time.

    This seems the cleanest and most maintainable way to me to do something like this, but as stated above, this is high level conceptual stuff and have to still do a proof of concept.

    For more about dependency injectors / containers see this blog: IoC Container Benchmark - Performance comparison

    Hope that provides you with some further ideas.


    Regards, Xander. My Blog

    Monday, October 27, 2014 12:22 AM
  • Thanks Xander.  It sounds like we're trying the same thing, and have the same concerns about 'linking' custom client code into the main app.

    How nice it would be to simply compile those custom, client-specific rules into a separate class library/dll, and then drop it into an agreed upon folder for runtime loading and execution.  That way, we have one LS app and separate, individual client projects, all conforming to an agreed upon interface(s).  Deployment would then mean pushing the main app to (for instance) Azure, with the custom dll along for the ride, per client.  

    And when the client's needs change, load a new dll to the cloud and away you go.

    Haven't seen Simple Injector yet, will have to check it out.  For my part I've looked at MEF as well as reflection.  If you're interested a great tutorial on MEF can be found here:

    http://www.codeproject.com/Articles/376033/From-Zero-to-Proficient-with-MEF

    ..whereas a good refresher on reflection can be found on Pluralsight, in Jeremy Clark's course.

    Monday, October 27, 2014 2:10 AM
  • How nice it would be to simply compile those custom, client-specific rules into a separate class library/dll, and then drop it into an agreed upon folder for runtime loading and execution.  That way, we have one LS app and separate, individual client projects, all conforming to an agreed upon interface(s).  Deployment would then mean pushing the main app to (for instance) Azure, with the custom dll along for the ride, per client.

    And when the client's needs change, load a new dll to the cloud and away you go.

    Well this should indeed be possible if we use the concept of MEF (sounds more appropriate than IoC based on the codeproject link you provided) and I can't imagine it being that complex to get working.

    I've not tried Simple Injector either, just saw a post where they referred to the above linked performance comparison and made a point about that framework coming out tops.

    Let's keep this thread alive and share information as we go. I'm not sure exactly when I will be doing this but should at the very least do a little proof of concept at some point in the next month. I'm fairly optimistic that this must be the right way to go about that particular problem, right?


    Regards, Xander. My Blog

    Monday, October 27, 2014 2:22 AM
  • Yes, good idea, as I go along I'll post my findings here as well.  

    Regarding IoC containers, just as an FYI I've used Windsor and Ninject in the past.  Ninject *is* relatively slow compared to others but I like its ease of use, big community, and it has some nice advanced features (which I myself haven't used, but which do make it 'slower' than simpler DI frameworks.)

     As for raw speed numbers, I agree with the author's reply below that your IoC container is seldom the bottleneck in your app.  

    https://github.com/ninject/ninject/issues/84

    That said, Simple Injector looks to have excellent performance and a good feature set and sounds like a worthy entrant.  More power to them.  

    Monday, October 27, 2014 5:05 AM
  • Customisable server side rules for Lightswitch can give huge benefits. We've used them to great effect with the Silverlight client on past projects to run rules on property changes within the server, but these don't work with the HTML client. Additionally they can only be maintained by the development team.

    We've since had a major project which requires a HTML client and needs to provide heavily customisation calculations which are unique to each customer we sell it to. We therefore decided to build our own rule and workflow engine for Lightswitch.

    The rule engine has code generators that automatically attach to the Lightswitch server project’s save pipeline for most data sources including intrinsic, external and consumed WCF services.  Any table and field can have a rules which automatically fire when the client saves changes. No additional client side code required.  The rules run on the server and can change fields, access other tables, trigger a workflow to run sequences of rules and chain other workflows.

    Our rules are written in C#, but in theory any .NET language could be used.  The are written/edited at run time within a HTML client screen and are stored in standard Lightswitch tables. They are then compiled on the fly and attached to the running LS server.  

    We've only tried using the engine from the HTML client, but in theory it will also work from the Silverlight client or any other client accessing the server via OData.

    With a little JavaScript on the client, we can also hijack the save pipeline to make the rules run interactively like the old Silverlight client did.  E.g. the user changes one field and other fields update with values calculated in the rules.

    Due the flexibility it gives we are now planning to use it on future projects. This thread has us wondering if it's something others would be interested in.


    John

    Tuesday, October 28, 2014 10:31 PM
  • Hi John,

    Welcome to the LS forum - we hope to see many more posts from you!

    I would certainly be interested in what you have described above and would think that most LS developers would be interested. More information - perhaps a video - illustrating exactly how this works would be helpful. What is the edit experience like and how do you handle debugging?

    I don't know yet whether what you have described will totally meet all my custom business logic needs, but it could perhaps be combined with MEF/IoC approach for the real end-user type business rules. So perhaps I would need both as I also require business logic glued into specific points in my general manager type classes that sit between the WebAPI and the ServerApplicationContext.

    But as stated above, I think there should be a good potential audience for what you've described above so looking forward to more information.


    Regards, Xander. My Blog



    • Edited by novascape Thursday, October 30, 2014 2:44 AM
    Thursday, October 30, 2014 2:44 AM
  • Hi John,

    What you've done sounds very interesting indeed, and quite a bit like the App-Stitch product that Jan van Der Hagen has created.  As with Xander I'd like any more info you care to share (how you're doing workflows for instance), so we know what's possible.  Welcome aboard!

    Thursday, October 30, 2014 11:10 PM
  • Hey all,

    thanks for linking to app-stitch ;-) We got a lot of features planned so I'll keep an eye on this thread for more feature ideas!

    If you install PowerProductivityStudio, you get free 'generic events' in your server application by implementing the PowerProductivityStudio.Extensibility.ServerEventHandler interface (just implementing is enough).

    From there, you can use whatever you like, like ScriptCS to load CS dynamically, Roslyn to load CS/VB dynamically, or a MEF directorycatalog to pick up assemblies with custom code dynamically.

    Sounds like a fun project, and if you keep posting your use cases to this thread I'll make sure we consider them for app-stitch.


    Keep rocking LS!
    Jan

    PS: have you seen app-stitch yet? It's a visually simple yet powerful way of designing business rules for Visual Studio LightSwitch apps.

    Thursday, October 30, 2014 11:34 PM
  •  

    .

    The rule engine has code generators that automatically attach to the Lightswitch server project’s save pipeline for most data sources including intrinsic, external and consumed WCF services.   


    John

    Hey John,

    I'm wondering if you could share what technique you applied to accomplish this? No details, just a rough idea?


    Keep rocking LS!
    Jan

    PS: have you seen app-stitch yet? It's a visually simple yet powerful way of designing business rules for Visual Studio LightSwitch apps.

    Thursday, October 30, 2014 11:36 PM
  • Actually, thinking about it...

    app-stitch already supports multi-tenancy.

    We could add a trigger for the 'filter' events that occur in LightSwitch. We could then also add an action 'filter the entities' where you could just type your lambda expression to do row filtering.

    In addition, we could also add an action 'execute code block', in which you could execute your random C# or VB. 

    Hmm sounds like a great weekend project actually, but I'm booked full until mid next week. If you can wait that long, I'd be happy to implement these features by end next week!


    Keep rocking LS!
    Jan

    PS: have you seen app-stitch yet? It's a visually simple yet powerful way of designing business rules for Visual Studio LightSwitch apps.

    Thursday, October 30, 2014 11:46 PM