Hiding business logic in database, but how do you hide in server side BOs

Hiding business logic in database, but how do you hide in server side BOs

Old forum URL: forums.lhotka.net/forums/t/9740.aspx


timster posted on Wednesday, November 10, 2010

We are designing an applicaiton that will run within a security hardened,  networked, application server  "appliance" which is accessed from winforkms applications installed on a number of clients machines.  Some of the business logic is is confidential and we are considering using encrypted Stored Procs in the appliance's database to hide this logic from prying eyes.

I know we can use obfuscation but supposing we wanted to hide some business logic in the server side business objects, not in the database, but we didn't want this logic to exist on the client machines (in our case its a calculation).  We could use web services, but then we loose all the data binding, N level undo and so on that CSLA.NET based objects provides.

It seems that I need different objects on the server to those on the client and could implement this with an additional tier, but this seems to need a lot of duplicated code.

Anyone got any ideas / design patterns / examples aboiut how I can do this without having a code management nightmare?

Thanks

Tim

Savij replied on Wednesday, November 10, 2010

Tim,

If you are using csla 4 you can do this. Just setup your files to run client and server side like you would for silverlight. You would have one bl.client.cs and one bl.cs and one bl.server.cs. All three classes would be declared as public partial bl {}. Link the bl.cs to the client project and leave the original and the server one in a server project.

Now just create an async business rule on your property that is databound. Your propietary code will reside only on the bl.server.cs which is only deployed to your secured server. The answer would come back async and automatically be databound.

I am sure you can do this as well in a non-async manner, but I have never tried it that way as our client is Silverlight when I tried doing something similar.

Let me know if that helped!

[EDIT]

Tim, I may have spoken too soon, what I describe above still leaves the business rule class in the bl.cs class which does end up on the client. I think to make it work, you can put the business rule class in both the bl.client.cs and the bl.server.cs. In the client side, the business rule will call it's execute method which would have no implementation, but on the server side your business rule class would hold your propietary code. That should work, but again I have not tried it.

-Jeff

timster replied on Wednesday, November 10, 2010

Hi Jeff

Thanks for your prompt reply - but what if I am using 3.8?  Is it possible to do similar things with that version?

Regards

Tim

Savij replied on Wednesday, November 10, 2010

Yes, I think 3.8 also supports the split tiers because 3.8 is what the silverlight videos are based on.

-Jeff

timster replied on Wednesday, November 10, 2010

Jeff

Thats brilliant - I will experiment and let you know how I do.

Pretty obvious really - I'm kicking myself for not thinking about it before!

Thanks again

Tim

Savij replied on Wednesday, November 10, 2010

Lemme know how it goes....

-Jeff

RockfordLhotka replied on Wednesday, November 10, 2010

If it were me, I'd try to do this in a clean OO way, by having the business objects collaborate with (call) other objects that are only installed on the server.

So all your server-only logic would go into its own project (assembly) that is only deployed to the server. Your business library project will reference this project, but will only call it when you know the code is executing on the server (in your DataPortal_XYZ methods for example).

Remember that the .NET type loader only loads types (and thus assemblies) on-demand. Your business library, when running on the client, still references the server-only assembly, but if you never use its types, .NET won't try to load it (and fail of course, because that assembly wouldn't be found on the client).

No compiler directives or duplicated code - just basic OO separation of concerns and collaboration.

timster replied on Sunday, November 14, 2010

Rocky

Thanks for your invaluable insight into this one!  The partial classes solution does work but I will try your solution as well - its really only a couple of methods anyway so its no big deal plus the compilation and distribution for your solution seems to be a lot easier to manage.

Thanks again

Tim

timster replied on Sunday, November 14, 2010

The partial classes solution you outlined but when logging back into the forum just now I noticed Rocky's solution, so will try his solution as well.

Copyright (c) Marimer LLC