Beginners design/patterns question

Ummm - MVC for the whole thing? That's gonna cost in terms of maintenance and flexibility.

Dean, if I am understanding your underlying question correctly, you are looking for an example of an enterprise architecture, explained using patterns as a means of communicating concepts.

As you may guess, this topic is huge, and difficult to condense down to a few buzz-words. That being the case, let me take a crack at it.

First of all, let's define the physical architecture of this thing. Froma a conceptual level it really doesn't affect the design of the application you identified, but it helps to understand context. For the sake of argument let's assume that you are planning on running a three-tier architecture - a web server for the presentation layer, an application server for the business logic layer, and a back end RDBMS.

Assuming that this architecture is right, let's talk about what goes where. On the presentation layer you want to have code running that will generate your user interface (web pages). A good example of such a tool would be the Struts framework. Struts itself is a pretty decent example of a Model View Controller pattern implementation (data and presentation logic are separated).

Now the challenging part comes in. If you are following the architecture identified above, you need to communicate with a separate tier to interact with your business logic. The shortcut that a lot of teams take is to do the DB connections directly from the presentation layer. But if you ever change your presentation layer you need to completely recode all of your business logic in the new presentation layer. Bad idea. So, what you want is a separate tier that handles your business logic. More on this tier in a minute. The real challenge is making a useful connection between your presentation and business logic tiers. This is where the pattern of "Value Objects" come into play (Value Objects is a common J2EE design pattern). Value Objects are responsible for shuttling data between a biz logic and a presentation tier. Here's the cool part. You already need "models" for the MVC presentation pattern, right? Why not make these Value Objects your models?

(sidetrack: what we are getting at is a concept called pattern based architcture - you can express relatively complex software architectures in terms of several cooperating design patterns).

Meanwhile, back at the ranch - we are now on the Biz Logic tier. This layer can be as simple or as complex as you like, and usually you are going to be talking about a variety of design patterns to quickly express how things are going to work on this tier. Let me give you an exmaple from a project I am working on. In my project, the business objects are "serviced" by a series of "agents" - each responsible for handling a different service for the business objects. In my system there are only a limited number of specific agent types to handle a large number of business objects, so I usually express these agents with the design patterns Singleton, or Pool. There are a lot more patterns in my actual application, but I can see your eyes glazing over already.

On to the persistence tier. Now the challenge is to take information (data, possibly state information) from the business object layer to the persistence layer. As you might have guessed, there is another design pattern that identifies what we are looking for - it's called the "Data Object" pattern. Unlike the Value Object mentioned previously, this pattern is responsible for knowing how to store and retrieve business object data into a persistence mechanism. Data Object is also a common J2EE design pattern.

So there you have an end to end architecture, defined in terms of design patterns. On the front end you have a presentation layer defined by the MVC pattern. From there communication takes place with a business logic tier via the Value Object pattern. Various patterns can live in the business logic tier. Between the Biz logic and the persistence layer you have Data Objects that know how to store and retrieve biz object data.

Clear as mud? The next step is to go and hunt down information on these design patterns and really understand what they imply. After that, build something based on these patterns. You never really get to know the power of patterns until you use them as a "blueprint" for building something that really works.

Jonathan House

jonathanhousea at 2007-7-12 3:57:45 >