September 2, 2002 at 10:30 am
Can other members advise please:
I have written a 2-tier business application where I am progressively migrating business logic from the client to t-sql as my knowledge increases etc.
However, another consultant has advised my client that this logic should in fact be incorporated into a middleware tier so that it is not in the same place as the data. This leaves me in a bit of a mess - what have other sites done to address this apparent conflict?
TIA,Simon
September 2, 2002 at 7:48 pm
Usually you end up with a bit of both. If you can easily encapsulate business logic in a stored proc I dont see that as a bad thing. Easy to change if needed and you get the perf boost from a compiled proc. Most of the time business logic is convoluted and better described in a "real" language in the middle tier. Long term if you're planning to run on platforms other than MS SQL then you can avoid most of the porting issues by keeping the code in the middle tier. I say most since all the SQL variants have their quirks, so if you use proc's there will probably be changes. On the other hand we have a system where they avoided procs altogether to abstract themselves from the platform - it works, but perf suffers a lot.
Andy
September 3, 2002 at 1:49 am
Thanks Andy,
I suppose my follow-up question has got to be: which proper language should be used for the middleware? With .Net announcing the the end of COM, where does that leave me?
Regards
Simon
September 3, 2002 at 3:56 am
Hi Simon...
you could possibly do it this way...
* use stored proc have part business logic and
* the component tier to have the rest of BL and responsibility to call Stored Procs...
There would be a performance penalty.... (compared to direct call as in fat client or fat server)
As for COM or .Net components ... you can use COM or .Net to create the components and then use COM+ to access them... in that way u essentially shield yourself from the application tier.... so u can use VB/VC/ASP with .Net components or VB.Net, C# etc with COM components.
Regards,
Dave
Regards,
Dave
September 3, 2002 at 5:05 am
Com or .Net, take your pick. We're moving to .Net at work for new projects, no plans to migrate everything. Yukon is rumored to have support for .Net languages in stored procs, that should make life interesting for everyone.
Andy
September 3, 2002 at 5:15 am
I suppose my initial concern is the alleged performance overhead of no longer interacting directly with the database. I always thought it was better to put data intensive code as close to the data as possible? Is there any guidance available for best practices in this area? I have a mix of both internal clients and web-based remote users. Scalability is involved as well, but ultimately doesn't it all come back to the data server as the start point for this model?
Regards
Simon
September 3, 2002 at 9:59 am
Trade offs everywhere, no way around that and no one answer fits all. Makes sense in some cases to take load away from your db server, let it do what it does best.
Andy
September 4, 2002 at 7:53 am
When you're dealing with both internal and web clients, you have to move to a model where all BL is situated 'server side'. Be it in a middle tier or in the database.
Any choice of platform is good, as long as you can integrate with your current (and future?) apps. Database, COM or .NET are all good candidates.
As far as the performance penalty is concerned, you can have some kind of precompiled execution plans, even in the middle tier.
This used to be possible in the old days using the ODBC API (SQLPrepareStmt, if I'm not mistaken). Don't know by heart how to do it in ADO, DAO and .NET.
My personal experience is that you have to avoid scattering your BL in all tiers. This is probably the worst you can do.
September 4, 2002 at 8:00 am
Well thank you to everyone who has responded. I'm not absolutely certain that I am any clearer on what I'm supposed to be doing!! Is the use of middleware actually of any benefit in many cases - the comments about performance penalties ring alarm bells with me, that's what I'm trying to get away from...
Regards
Simon
September 4, 2002 at 8:29 am
Unfortunately though Stuart, the problem there is that I cannot commit lots of resources unless there are going to be tangible benefits. So that's really why I'm here to find out some opinions from the members before launching into something.
September 4, 2002 at 9:06 am
Without too much more waffling, I'd recommend that you go with three tiers, put the business logic in the middle tier, use procs for all data access, keep in reserve the option to put certain perf critical sections of business logic into the proc directly only if becomes a bottleneck. Thats a pretty standard pattern these days and works well all round.
Andy
September 4, 2002 at 9:15 am
Well Andy thanks for your terse reply. It's a pity you haven't read the rest of this thread, where you'll see that your 3 tier approach is questioned. Anyway, I have my answer now, so I won't bother you again.
September 4, 2002 at 10:15 am
On the contrary, I did read the thread and even posted earlier. Everyone will have different opinions on what is best, mine not any better than anyone elses. So what did you decide to do?
Andy
September 4, 2002 at 10:40 am
the gains from a middle tier come (with a well designed app) from offloading CPU cycles from the web server and the sql server onto another box. Like crunching numbers that are too complex for sql or not worth doing.
Don't forget that the SQL Server is a shared resource and a single point that is hard to scale up without $$. Easier to add 2 middle tier boxes than split data to 2 sql servers or upgrade your sql server. Same for the web servers. Why put a web server on a separate box from sql? Easier to scale out.
Steve Jones
September 4, 2002 at 10:50 am
Thank you for your continuing advice. I'm thinking that I will have to bite the bullet and implement a middleware layer. Are there guidelines available for starting to write a middleware layer from nothing? Do I assume I write it in something like VB or C#? Do I have to do anything clever in order to install it on multiple servers, or is that handled by COM+/DCOM/whatever ?
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply