|
|
Posted by eric.schleicher on 04/11/07 17:58
On Apr 11, 5:34 am, "Andy Dingley" <ding...@codesmiths.com> wrote:
>
> Be careful when conflating N-tier with MVC. You can produce some
> braind-dead pseudo-MVC that way.
>
Is DUML an n-tier implementation? It seems that could be part of one,
but that's all backend (server) engineering. Straight Ajax and hefty
client javascript view controller logic does not an n-tier make. In
most solutions I've seen, the closest description that comes to mind
is not even tiered, and bears more resemblance to italian pasta. It's
seems DUML+IAML together fit very nicely within MVC and n-tier.
> -----
>
> If you're using AJAX, why are you duplicating a "view" onto the
> server? This is my basic criticism ofDUML- it's a server-side
> rendition of a view that doesn't (and shouldn't) exist until it hits
> the client.
I think that there is a very compelling argument that most if not all
current AJAX applications are guilty of the "duplication". Pushing
the view controller out to the client is OK, but the rubber hits the
road when complex business requirments compromise the ablity of the
view controller to be isolated on the client. Invariably, the end
result has shipped the business logic out to the client, where it
clearly doesn't belong. This is an egregious violation of n-Tier
design, AJAX or not. The end result are applications with gobs of non-
view related logic residing on the client, where debugging is a
challenge, and the bittle nature of DOM is exascerbated by no clear
delineation between view controller and business logic since most
developers are just excited to get it work, let alone have it conform
to any respectable design pattern.
>--------
>
> Abstract SOA architectures should only provide a model. They can't do
> this in practice, so SOA-based interactive applications in particular
> find themselves implementing a controller too. They certainly
> shouldn't be implementing the view though, that sits as close to the
> client as possible.
Why? One of us must not understand what SOA is and where it's best
consumed in an application context. It's always been my understanding
that SOA is best consumed by the model controller. and then the view
controller determines how it's presented. Am I missing something?
>If you have AJAX, then you instantiate the view on
> the client. If you only have a dumb HTML client, then you might have
> to push view-generation back to the server (that's OK too). What you
> should avoid is having AJAX available yet getting no more benefit from
> it than access to a server-geneated view.
Really? There are incredibly synergies realized from having the model
and view controller both on the server. The AJAX providing "Just" the
view generation is a strength. You end up with light weight clients,
a proper development environment, and well formed MVC and n-tier
ability for free.
>What's _really_ bad isDUML,
> the idea that some client-DOM-tweaking language has any justification
> for being anywhere near the server. That's even a retrograde step back
> from 1991 HTML.
It's my understanding that in DUML, the DOM "tweaking" still happens
on the client, but based on instructions from a server, how is that
any different from shipping all that logic out to the client, where
debugging is a huge PITA.
-Eric
Navigation:
[Reply to this message]
|