Allow me to interject this opinion: The mid-tier is not about business logic. It is about scalability.
I think it's a common misperception that the reason we separate things into three tiers is because it gives us physical separation based on *application* functionality: UI on the client, business logic on the mid tier, data management on the database. IMO, the real separation is based on *infrastructure* functionality. Clearly, the UI has to be on the client (ignoring the smearing that occurs with HTML UIs for a second). But where does the rest of the functionality go? Well, look, the two things we know is that we're going to store the data in a database, and that we're going to use transactions to get at it. No argument on that point, right? Notice I didn't say *distributed* transactions. Just transactions. OK, so where do you put the logic that accesses the database? Well, if you put it on the client, you need a connection per client, plus, you need to poke a hole in the firewall that goes straight to your DB. Both of these options are untenable from an infrastructure standpoint. Worse: with transactions in the picture, the high latency of that connection means that locks will be held for a really long time any time a transaction spans more than one operation. But without some other layer involved, we're screwed. Enter the web server. You're probably using HTTP to get from the client to the target site anyway, whether that's via XML or via HTML. If we connect from there, look at the benefits: we only need one connection per *active* client. Connection pooling lets us get away with a much smaller number of connections. Plus, the lower latency that comes from the fact that the web server and the database are on the same network means that if we do have multi-roundtrip transactions, the locks will be released sonner. But wait! As long as we're optimizing, why not move the transactional code off the web server entirely? Stored procs being a good way to do this, at least from a performance standpoint. Locks will be held for a minimum amount of time, and it makes it easy to design a stateless web server, which means we can easily scale it out by load balancing across a number of web server boxes. That *still* leaves connection pooling as the responsibility of the mid-tier, and it's *still* a huge win. Last time I checked, it took like 0.5 seconds to connect to an Oracle box. Any time you can avoid something that takes so long a user can actually perceive it, you're winning. Anyway, the point of my argument is not so much that you should use stored procs. It's that the *real* point of the mid-tier - the thing you can't get with a two-tier architecture, is session concentration, and that it's a big win. > -----Original Message----- > From: Moderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED]] On Behalf Of Rui > Dias Quintino > Sent: Friday, May 17, 2002 6:27 AM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier > > > Hi again, > > One note on Business Logic and Peter thoughts. Peter, you are > absolutely right, in fact in all the projects I've > participated that was the case. There's no workaround for > that, unless we are willing (I am not) to round trip every > time, as you said. > > I know that not all the business logic can go in the middle > layer, but dependending on the project itself it maybe be > usefull to replicate common UI controls validation at the > business layer also, this is common in a web scenario where > most of the times we can not trust client validation (it is > there only to provide rich and responsive user interface, not > to be secure). > > > I guess the experience of each one of us makes a point here, > there are rules that we can delegate to UI layer, there are > rules that must ensure at the business layer (that may > possibly be used by many different client applications, web, > win32, web services, etc, not directly controlled by us) and > sometimes we can code the rules at both layers (when we > control both the middle, and presentation layer. not possible > if we want to expose our middleware components through web > services for example). > > There's one last option, code our middleware in such a way > that it can respond to questions like "What type of > validation do I need to do to this entity before I submit the > data to you?". I've seen this and I've tried it a few times > with some degree of success. As long as our client > understands our answer it can react acordingly and switch to > a responsive UI experience. We still have the control of our > business rules. We may still ensure the same rules at the BLL > (server side) to satisfy security/integrity requirements. > > > >"So business logic is in fact spread throughout a good, > modern, usable > system." > > It's like I said, we are evolving in circles. It's a fact, > that's no problem with that as long as we all can learn from > our own mistakes. I certainly try to. > > On your other notes, I'm still reading, and thinking, and > thinking... Thanks everyone once again. > > Best regards, > > RQ > > -----Original Message----- > From: Peter Foreman [mailto:[EMAIL PROTECTED]] > Sent: quinta-feira, 16 de Maio de 2002 16:50 > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier > > > Inline: > > --- Rui Dias Quintino <[EMAIL PROTECTED]> wrote: > > -Team A develops some SuperTransactional method, using > ADO.Net and SQL > > transactions, no COM+/DTC overhead. Team A is not aware if > this method > will > > or will not be used by other classes/methods developed by Team > > B,C,E.... > (in > > Enterprise systems, like the one we're dealing right now it will > > certainly happen in a matter of days) And when that happens, > > SuperTransactional > method > > won't be able to run in the very same transaction (as it > should be)... > what > > to do then? > > If supporting COM+ is a requirement (see below next point if > it isn't): > a) Use COM+/DTC > or > b) Add additional compensating transactions (where suitable > txs are not already present). Supply > COM+ users of each module with a wrapper which can fire compensating > transactions on rollback - > possibly a CRM. > > The choice depends on what your customers and teams B,C,D > want. b) is obviously more effort, but can also support more > diverse clients - you could build a Web Services interface to > your modular subsystem. > > > - We try to design the application in a way that all the > methods are > > built so they have all the transactional behaviour inside, but the > > implications > on > > the modularity/reusability of the classes will be huge. > Maintaining an > > enterprise application where the business logic is replicated > > everywhere > or > > simply not existent can easily get out of control. > > This is not about how you handle transactions, it is about > modularity. How modular are the teams subsystems? How > modular do you want to make them? How do you want to make > then interact? (COM+ is only one option for interaction - > only you can say if it is the most appropriate). > > If collections of methods are modular then business logic > should not be replicated outside the module. Are you saying > A,B,C,D are using exactly the same data, at a data level, > rather than having inter-module interfaces? If so, then it > isn't very modular. > > If the methods/modules are tighly coupled then they should be > designed together along a common architecture that allows > easy inter-operation, even if they are implemented by > different teams. This is true if you use COM+ or another > transaction control method. You need someone looking at the > overall picture if this is the case. > > In short: You need to decide how modular you want the whole > thing, and how you want the parts to interact. > > > - We face the fact that coding ALL the bussiness logic at > the Stored > > Procedure level is a perfectly valid option. The SP becomes our > > reusable, black boxed, component. We build all the middle tier with > > T-SQL. > > It is quick, but I've never liked going down the stored > procedure route from an engineering perspective. i.e. There > is not the same support for source versioning, deployment > control, debugging, etc that you get with component based development. > > > I try to develop all the code in a manner that I can easily switch > > between ADO.NET/COM+ transactions. That's my advice for myself :). > > Having this choice I'm currently testing both scenarios, > and I'm still > > thinking about using COM+ services. > > Wait 5 years until AOP becomes common then you'll be able to > separate this out into an Aspect. :-) > > > - Business logic at the middle tier isn't such a > great option > after > > all > > Ah! A particular tender spot of mine. You know people talk > about business logic as if it is something you can wrap up > and put in one nice little place. That's not correct IMO. > > Is business logic is separate from presentation layer? > The old transaction processing systems (which MS copied to an > extent when creating MTS), were largely terminal based > systems, with very little interaction at the terminal. > Presentation layer was taking some data and populating a > screen. Very little validation was done at the terminal > level. In this scenario business logic is pretty much > separate from presentation. In modern systems you want your > edit controls to be intelligent, therefore they need business > logic embedded in the control in terms of edit masks etc. > This is true of good web systems, and extremely true of GUI > apps. Do you really go for a roundtrip through the business > layer to validate these simple things? No of course not, > especially in the web model. Some controls by their very > nature have a lot of business logic built in. So business > logic is in fact spread throughout a good, modern, usable system. > > IMHO MS copied the terminology and idiom of > Presentation/Business/Data layers when the technology had > changed to a degree that the terminology is not really > appropriate any more. > > What people to refer to as a business logic layer, is nothing > of the sort IMHO. It is really a business transactions > layer. I usually refer to this as a transactions layer, > because the difference to the human ear between BLL and BTL > can appear too subtle. People can think they are the same. > > Peter Foreman > > > __________________________________________________ > Do You Yahoo!? > LAUNCH - Your Yahoo! Music Experience > http://launch.yahoo.com > > You can read messages from the Advanced DOTNET archive, > unsubscribe from Advanced DOTNET, or subscribe to other > DevelopMentor lists at http://discuss.develop.com. > > You can read messages from the Advanced DOTNET archive, > unsubscribe from Advanced DOTNET, or subscribe to other > DevelopMentor lists at http://discuss.develop.com. > > You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
