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.

Reply via email to