Apologies in advance, but what has that to do with business logic? I'm sure you could get the best industry professionals in the world, for instance on Dbs as you say, but if the whole architecture isn't right then problems of various kinds can occur in the short, medium and large term.
Those that said a) business logic depends on the application, and b) tiers should be separated are IMHO spot on. Replacing Dbs, servers, clients and so on should always be able to happen seamlessly over years. System architects, DBAs, developers all have relevant input. It is for the "board" then to decide, based on specs, the time/cost implications for a particular route. To give an example. I'm on a project at the moment which requires to access about 100 exchange APIs over the next five years, allowing for growth. It may use up to 1,000 servers in ten years, with potentially 250 million users. I've spent six weeks ONLY on deciding where the business logic will sit, writing code and analysing the effects on Dbs and different clients. One thing is for sure though, each tier must be wholly disconnected and disconnectable, for at the end of the day servers will change and exchanges will change their APIs. I find it difficult to see that a competent team would in any but the most simple environments enjoin a business tier and it's logic by directly coupling, not interfacing, with a data tier, no matter where that DT gets its data from. If that is so then systems architects, DBAs, developers (whoever) must interface too! I wonder, if wholly disconnecting the business logic from other tiers (I refer specifically to tiers, not layers) is good for a large scale development then why does it not also provide the paradigm for every other n-Tier development? Mike A. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.10.24/101 - Release Date: 13/09/2005 =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
