<snip> In many (maybe most?) enterprise systems, tiers are built by different developers. E.g. HTML/ASP/ASP.NET is written by one guy, business logic (VB com(+), VC/ATL com(+), C#. VB.NET) by another, and database structure and stored procs - by yet another.
Yet, for scalable systems, when implementing a feature you have a mix and match between all three tiers, and ultimately all developers need to understand issues in all of them (data/biz/prez). </snip> Developers should definitely try to understand performance and scalability implications in whichever tier they are working on. General knowledge of the "the next level down" gives the developer a good context for some decisions they make. However, to suggest that the presentation guy needs to know how the business logic, or db procs are working internally indicates a poorly factored system. You should be able to define non functional requirements that detail exactly what the performance and scalability characteristics for both the integrated system and its components. Don't get me wrong. I think it is important (for a lot of reasons) that developers cross these boundaries, but they shouldn't _have_ to know the details of the other guy's work. <snip> So how do we (philosophically) solve this contradition? </snip> 1) Well factored software architecture that clearly defines responsibilities and normalizes dependencies. 2) Frameworks to support the architecture. 3) Architectural patterns - to provide specific implementations by inputing well defined requirements into generalized solutions Cheers, Ed You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
