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.
