Do Design Patterns conflict with Layered Architecture?

[DS]

I'm trying to understand how these two concepts could work together
architecturally (if they can.) I realize both concepts provide benefits
of re-use and ease of maintenance. Which is important when you are
setting up multiple sites that are similar.

But it seems like using both Design Patterns and Layered Architecture
together would create conflicts -- especially in the area of keeping
layers loosely coupled (and even physically on separate server tiers
and possibly with Web Services APIs for each Layer on a service buss)
while still implementing system-wide patterns of design.

For example, consider an ecommerce system that has a Presentation Layer
(on the Web App tier), Business Logic (on the Middlewear tier), and a
Data Access Object layer (on the Database tier).

Along comes a PHP programmer with a JAVA background who believes in the
benefits of using Model-View-Controller (MVC) design patterns.

It seems like constructing "data objects" for creating the "Data Model"
are going to require closer coupling of Business Logic and Data Access
Layers.

It seems like constructing "view objects" for various role-based
interfaces and data states, and subsets of data (like date ranges,
etc.) may require closer coupling of the Presentation Layer and
Business Logic.

It seems like setting up "broadcaste r objects" and "listener objects"
for Controller events system-wide could require closer coupling of all
three layers.

Any opinions on how this seems at cross-purposes?

Thanks,

--Dave

[C. (http://symcbean.blogspot.com/)]

Re: Do Design Patterns conflict with Layered Architecture?

On Aug 9, 10:30 pm, DS <d...@noSpamPle ase.comwrote:

I'm trying to understand how these two concepts could work together
architecturally (if they can.) I realize both concepts provide benefits
of re-use and ease of maintenance. Which is important when you are
setting up multiple sites that are similar.
>
But it seems like using both Design Patterns and Layered Architecture
together would create conflicts -- especially in the area of keeping
layers loosely coupled (and even physically on separate server tiers
and possibly with Web Services APIs for each Layer on a service buss)
while still implementing system-wide patterns of design.
>
For example, consider an ecommerce system that has a Presentation Layer
(on the Web App tier), Business Logic (on the Middlewear tier), and a
Data Access Object layer (on the Database tier).
>
Along comes a PHP programmer with a JAVA background who believes in the
benefits of using Model-View-Controller (MVC) design patterns.
>
It seems like constructing "data objects" for creating the "Data Model"
are going to require closer coupling of Business Logic and Data Access
Layers.
>
It seems like constructing "view objects" for various role-based
interfaces and data states, and subsets of data (like date ranges,
etc.) may require closer coupling of the Presentation Layer and
Business Logic.
>
It seems like setting up "broadcaste r objects" and "listener objects"
for Controller events system-wide could require closer coupling of all
three layers.
>
Any opinions on how this seems at cross-purposes?
>
Thanks,
>
--Dave

Not really - the presentation / business / storage layers correspond
directly to the view / controller / model patterns. But the important
thing to remember is that MVC does not simply apply at the top level -
within the 'view' for, say, an appointments editor form, you may will
implement individual components using a MVC model - e.g. in a
component for managing the time of an event the model renders the
widget using the time and date it gets from the controller, and
returns the user amended data back to the controller. The controller
maps a UTC time to the users timezone using the appropriate date
format and language. The model handles interaction with the form's
model.

The view object for this component may in turn be composited of MVC
objects.....

C.