Hi again,
Thanks everyone for the replies. I certainly agree with Craig, using COM+
will cause bigger contention times at the database level. That's a fact, I'm
well aware of that (actually there isn't a day I don't spend some time
thinking and reading articles about this polemic issue... no perfect answer
yet).
My pratical problem:
-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?
- We deal with the fact that our database can easily become inconsistent and
in an unpredictable state (judge on a case by case basis I think)
- We pass ADO.NET transation references around different object classes,
since it's impossible to have all the methods in one class in our scenario.
(haven't seen a stable solution for this, ideias anyone?)
- 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.
- 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.
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.
I don't agree with loosing the middle tier, sometimes I got the feeling that
we are evolving in circles:
- We now have xcopy deployment (...DOS was all about xcopy
deployment...)
- Business logic at the middle tier isn't such a great option after
all
- COM+ seems to be completely an undesirable solution (except for
pure distributed transactions)
- Stateful objects aren't such a bad ideia after all
- ... :)
Regards,
RQ
-----Original Message-----
From: Craig Andera [mailto:[EMAIL PROTECTED]]
Sent: quarta-feira, 15 de Maio de 2002 20:24
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier
> This is really one of the best lists for .Net, thanks
> everyone for all the usefull tips I've been reading the last
> few days. But I've a question about this one. If we don't
> need distributed transactions, even if you have just one SQL
> Server database, and we choose not to use COM+ services how
> can we solve the problem of needing to span one transaction
> across multiple method calls (different classes/methods)?
Don't do this. Your performance and scalability will not be good.
Transactions=locks. Multiple methods=multiple roundtrips to the
database=longer transaction=contention=bad scaling characteristics. This
is an outcome of the speed of light, which is not really in our control.
At least, not mine.
> We'll end up with no business layer at all.
So what? Sorry, but the laws of physics don't care if your system has a
nice OO architecture that conforms to all the Booch-influenced thinking
that we were all trained to throughout the 80s. And more to the point,
neither do your users.
This discussion has raged since the advent of COM+. If you ask me, Tim
Ewald has totally addressed this in his book, which is an absolute
must-read for anyone thinking about writing transactional systems.
If I sound a little hostile or brief, it's nothing directed at anyone.
It's just that I hear the same OO refrain over and over again, and it
just doesn't play in the world of distributed transactions.
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.
