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 ??
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.
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...
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: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.
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