Business Logic in CLR

Business Logic in CLR

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


Vinodonly posted on Sunday, August 20, 2006

First of all, pls accept my multiple thanks for providing such a wealth of information in your book as well as providing a framework on which we can build such power n-tier applications.

i have one query and wanted to clear the same. On Page 45, of your VB version of Business objects book you have mentioned

quote

I wish this book included the secret that allows you to write all your logic in one central location, thereby avoiding all of these awkward issues.

unquote

With SQL Server 2005, we can run code written in VB or C# inside SQL Server, i was wondering that if we write business logic code one time in any of the .net language and then we can use the same code in any layers as well as inside database.

can you advise your comments on this aproach ??

cultofluna replied on Sunday, August 20, 2006

You're probably awaiting an answer from Rocky, however I wanted to say I like your idea. In an application I wrote a year ago using C# and SQL2K, I've added business logic in the database as well. I wrote several UDF that are used as checks on the tables in the database.
However I've got the idea with the CSLA this is not the way to do it. You use the database "basic" functionality (Tables, Keys, Index, Stored Procedures). The BO's taken care of the Business Rules. When merging these two, as I understand you want to do, you breaking the flexibility of n-tier again.
Also the flexibility of easily changing a DBMS is gone, because you're application is partly build in your database.
But hey, I'm a rookie on CSLA, so correct me if I'm wrong :)

Cheers,

Brian Criswell replied on Sunday, August 20, 2006

You basically got it right cultofluna.  The idea is that whenever possible, the business behaviour goes into the business object.  You can put validation into the UI and database, but it should be seen as supplementary and a means of improving the user experience or protect against people directly modifying the database.  It should not replace any logic in the business objects. 

Vinodonly replied on Monday, August 21, 2006

appreciate your input on my question..

kindly note that if the code is written in any .net language, the code is not lost in the database only. if the code is designed in that way where it can be called from within the database as well as from outside, then it can be reused if the database is changed except if the new database doesn't support code running from within database that has to be rewritten.

idea here is to create one time business layer and run it from both places i.e. within database as well as from outside.

currently, i'm just talking theoritcally to get comments and feedback from other developers. i will have to write code and test it, if it really works.

pls advs your comments.

david.wendelken replied on Monday, August 21, 2006

I did a similar thing in the Oracle environment with Oracle Forms in a client/server environment, because the database and forms shared a common language, Pl/Sql.  I had very good results.

Be aware of the following potential gotcha's:

1) Thread-safe vs. non-thread-safe.  I'm new to .Net, so I'm not sure if you could get bit here or not.

2) Database Overloading.  If the database or the network connection between the web server and the database is your choke-point, you just made it worse.

3) Scaleability: You can add more web farms to take load off the webserver, but adding more database horsepower to take the load off may not be possible.  Depends upon your database vendor (and your $$$ budget).  Of course, if you are clever on how you go about it, you might just be able to move the objects to the web server instead.  (The mobile objects portion of the Csla framework might help here, but that's just a guess on my part.)

4) Oracle did a similar thing by allowing Java to be put in the database.  It was horribly slow and "not ready for prime time" when they did it.  You may not want to take the risk of pioneering this if MicroSoft has a similar record of development readiness at product release time...

 

Vinodonly replied on Monday, August 21, 2006

These are some very helpful points which i have to see, i beleive now i have to start coding and do some experimentation to see actual results.

thanks for your help.

RockfordLhotka replied on Monday, August 21, 2006

The idea is seductive, but on the whole I think it is a poor one...

Of all the tiers (UI, business, data), the hardest and most expensive one to scale is data. So the more processing you put into your data tier, the less ability you have to scale up to meet future demand. Putting your business layer in the data tier is a valid choice, but an expensive one.

On top of that, there are the real-world limitations of SQL-CLR. There are quite a number of things you can't do within that environment, and the reasons for those limitations are very sound. Remember that the CLR code running in SQL is really running within the broader context of the SQL engine. You could, with just a couple lines of code, degrade the performance of the whole database. Or you could destabilize the engine, causing SQL to fail. Microsoft has done what they can to prevent both these possibilities by restricting "dangerous" .NET features - but even that isn't foolproof.

CSLA itself can't run in SQL CLR due to these limitations. The reason is because CSLA uses dynamic assemlby loading - which is a prohibited feature. Sure, you can force SQL CLR to allow that feature - but then you are defeating a safety measure that is there to protect your database and your data integrity, and I surely wouldn't recommend taking such a step...

Various other related issues exist.

But perhaps the biggest issue is that updating assemblies into SQL CLR is non-trivial. This restricts the speed at which changes can be made to your system. While ClickOnce allows easy upgrades of clients, and xcopy deployment allows easy upgrades of app servers, the impact of upgrading assemblies within SQL Server is higher. And that's just the technical reality - it doesn't include having to deal with DBAs, who typically would prefer that nothing in the database ever changes Wink [;)]

david.wendelken replied on Monday, August 21, 2006

RockfordLhotka:
The idea is seductive, but on the whole I think it is a poor one...

Of all the tiers (UI, business, data), the hardest and most expensive one to scale is data. So the more processing you put into your data tier, the less ability you have to scale up to meet future demand. Putting your business layer in the data tier is a valid choice, but an expensive one.

Rocky,

I would very much like you to contact Paul Dorsey of Dulcian, Inc.  (www.dulcian.com) about the above statement.  Paul is a noted Oracle database expert (do a google on him) who also has a good deal of Java experience - and his conclusions are exactly the opposite of yours. 

He maintains that putting the logic in the database speeds up the application, not slows it down.  He's gone so far as to even put a good deal of UI flow control logic in the database because of the speed improvements.

You both might find it a very interesting conversation.  I know I would!

Paul's been working hard to get OO and Relational folks to put their heads together, and he has financial resources to help that happen. 

DansDreams replied on Tuesday, August 22, 2006

I would bet that his conclusions are not exactly opposite after all, but rather Rocky and Paul are hanging their proverbial hats on completely different points.

Sure, running code that processes data as close to the database as possible is seems like an obvious performance enhancer .  But when you start choking the living crap out of a relatively expensive piece of technology and have to start spending tens of thousands of dollars on SQL licenses and additional hardware, etc. just to get back to where you would have been it requires much more analysis.

Truth is, as Rocky explains in the book, there are many ways to trade off performance vs. security vs. scalability vs. cost vs. maintainability yada yada yada.

I think the conversation would be very interesting though.  One of the things I think would make conferences like VSLive 5 times more valuable is to have roundtable "debate" types of discussions where two people that have taken obviously contrary points of view meet face to face and discuss it, perhaps based on questions from the audience, or not. 

Rocky vs. Shawn Wildermouth, Rocky vs. Paul Dorsey, etc.  (Can you hear the Rocky theme music playing?  LOL)

Copyright (c) Marimer LLC