FREE Subscription to Dr. Dobb’s Digest: Same Great Content, New Digital Edition
Site Archive (Complete)
Architecture Blog: 'Simple' Three-Tier Architectures
Architecture & Design
PATTERN LANGUAGE

Modeling, Managing, Making it Right.

by Jonathan Erickson
IF YOU BUILD IT

... Will they Come?

by Arnon Rotem-Gal-Oz
August 10, 2006

'Simple' Three-Tier Architectures

I often see on forums questions like "I've just been entrusted with developing an architecture for XYZ, but I'm new at this. Can anyone tell me where I can find information on the appropriate architecture?" or "I have this simple 3-tier architecture I am building. Should my UI call the DAL or should my BL do that etc.?"

Surely enough kind members of the forum will point these poor souls to vendor X or vendor Y shelf architecture which clearly (yeah, right) explain how to do their favorite architecture du-jour.

I have one thing to say about this: Architecture cannot be defined without context and specific requirements. Okay it can, but the end result of that defining architectures *without* context or requirement is either something which is way too complicated ("we have two clients doing data entry and one server, but we have all this AJAX, web-services, Oracle RAC--okay so we have 2 servers--and an ESB infrastructure to boot") or too simplified. In any event, it likely doesn't fit your needs.

This is not to say that made-by-vendor components (Microsoft's application blocks now dubbed "factories", for isntance) can't be used as-is (or adapted) to your architecture. However this will most likely come with a price tag and you need to understand the implications and the effects of this choice on your application. The chances that you'll get a perfect fit are very low. For most application, this would either be too simplistic or too complicated. Think about your system's quality attributes before you commit to some off-the-shelf architecture.

Posted by Arnon Rotem-Gal-Oz at 09:44 AM  Permalink




 
INFO-LINK