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.
