[EMAIL PROTECTED] schrieb:
+1. The first thing I always preach new developers
on my team is that they should think the entire web
tier away and replace it (mentally) with a Swing or
whatever client, without changing anything in the
subsequent layers, and the application still has to
work as usual. From an architectural view, the
entire OO thing is about loose coupling, separation
of concerns and minimizing dependencies. Now
MVC - a pattern emerging from its first Xerox in-
carnation some 25 years ago, originally invented
for SmallTalk-based rich clients and targeted at
helping to coordinate keyboard input, 'business logic'
(as understood back then, mysteriously named 'Model')
and monitor output in a responsibility-oriented way,
has since been adapted to different technologies
including the web. Still, it's strictly about getting
input and showing things from the Model. Now,
unlike in the old days, applications are usually
architecturally somewhat more complex now-
adays and split into different layers (naming varies).
Usually, there's at least one layer for the 'business
logic' (a.k.a the application) and a subsequent one
for resource access. Both of them are relative long-
lived compared to the client (web) tier which can
change every few years, from Struts to JSF or
whatever, whereas the business logic itself tends
to stay relatively static (usually the database itself
is the part with the longest lifespan, database models
easily reaching the age of 30 or more). There-
fore, IMHO it's a good idea to keep heed of
a strict separation of architectural layers
throughout the entire application, providing
interfaces like BusinessDelegate or Facade
to be used by different client implementa-
tions in a consistent way even in case of
a complete technology change in the client
tier. This may possibly require more work
to keep thing as abstract as possible, but
I'm quite confident it'll pay some day. And
that's where DTOs (or ValueObjects, which
originally were designed to address granu-
larity issues when dealing with EJB and the
like) or domain classes come in. I, for once,
don't want to see *any* web-related stuff in
my backing layers; no document/view con-
siderations here. Better leave that ground
to the few remaining MFC adepts who still
think C++ is the one true solution to every-
thing. MVC, then, was born as a 'client' pattern
and stays one. YMMV, as always :-)
-- Chris.
-----Original Message-----
From: Dave Newton
I'm still not clear on how the entirety of MVC is the V
It's not. MVC is a View Tier pattern, though. Within the pattern it
separates the Model, an abstraction of the business logic, the View,
which displays a representation of the Model, and the Controller, which
translates user input into requests to the Model. The point is to bring
clarity to the Presentation Layer. See
http://idiacomputing.com/moin/LayeredArchitecture#head-386ccace28b9d5122
1f9ed6fe4dc1c59581ef0b5
Many people learning MVC for the first time mistake this presentation
layer pattern for an architecture of an entire application.
- George
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
