|
|
Posted by bkardell@gmail.com on 04/11/07 22:22
> Be careful when conflating N-tier with MVC. You can produce some
> braind-dead pseudo-MVC that way.
I don't necessarily think that I am conflating them if you read the
rest of the paragraph and take it in context. The thing that N-tier
and MVC share is the clear seperation of presentation, data and logic
- the difference is in communication and in my opinion largely
theoretical and not really worth discussing here since even in N-tier,
the presentation tier needs to deal with drawing some kind of data
(model). I don't mean to minimize anything - just want to focus the
conversation and not go off on a tangent. If you disagree, please let
me know why you think that this is so critical a point and we can talk
some more.
> If you're using AJAX, why are you duplicating a "view" onto the
> server?
Not duplicating - let me be extremely clear on this point: There is no
duplication in DUML. Models/views (in the form of markup) and
controllers exist on the server, only a proxy/interpreter exist on the
client. In the model that you are advocating, a much more gross
violation is likely of duplicating (or creating additional) layers of
logic and model. In the DUML model all actual modification of the
tree is done via the interpreter on the client, but the logic that
says what should be modified comes from the server. The instantiation
of the view (the tree) is what exists on the client - as it always has
been: Contrary to popular belief markup != tree. Markup is code, tree
is instance. Markup describes tree. View logic writes markup.
I realize that the initial impression is that this would seem to
indicate that you have to have some kind of simulated tree on the
server to keep track of what is going on, but in practice this
couldn't be further from the truth and I can virtually guarantee that
the alternatives are doing every bit of work on the server that most
applications currently using DUML are - and then some (as well as
much, much more on the client). When you think of HTML you think of
documents that contain thousands of nodes. When you think about AJAX,
you think about all of the single node manipulation that you have to
do to make it happen. While you have that ability in DUML as well,
being able to replicate all of these complicated node manipulations as
simple markup invariably leads to simple, elegant design that does not
require such. Even the structure of the language itself (its fail-
fast nature and the ability to condition manipulations) helps prevent
this kind of scenario.
>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.
It doesn't exist until it hits the client (see above), but I don't
think that you stated that quite how you meant it so let me clarrify:
Essentially you want the Web browser to work like a fat-client program
that is installed whenever you go to the page... Is that it? I know
that that might sound argumentative or condescending and that is not
my intent - it just seems to be the simplest way to describe it... If
that is the case - why not just write a fat client in any number of
technologies with auto update - almost any of which would be
considerably more secure, faster and more robust than the Web browser?
> 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.
Why can they not do this? I have personally worked on a team which
implemented SOA in precisely that way. Maybe I am misunderstanding
what you mean by the "this" that they can't do... Can you explain?
>They certainly
> shouldn't be implementing the view though, that sits as close to the
> client as possible. 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. 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.
This is the second time that you have made the statement that this is
a retrograde step from "even 1991 HTML" (or something like it) and
stating that somehow you get more 'benefit' from the alternative. I
have two comments about this. 1) HTML, at least well implemented
HTML, has changed remarkably little since the 90's - and so has the
browser. This is the technology. It is based on documents and based
on trees and the only reason we ever developed Web applications with
it in the first place is because it provides a thin, universal client
which requires 0-install and allows businesses to write and maintain
the whole thing on the server - including the simple, markup based UI
- using whatever technologies please them today. If that's not what
you want... If you want the 'benefits' of a fat client - again - why
not use a more rational technology for the job. 2) Please - PLEASE
explain the benefit of the alternative. That it makes our thin client
fatter? That it adds lot and lots of complexity? That it moves logic
into the Web browser where it's insecure, harder to develop, test and
debug, has limited memory resources, easily leaks, often requires
security hacks (ie. script hack) to develop something 'good', etc.
etc.? Or is it just really about this idea that somehow you can then
'easily' develop a new SOA-based client in whatever technology you
want very quickly - Because apparently we disgree on several points
there: a) that you can not/do not get the same from a DUML approach (I
say you can because SOA can be consumed on the server where it makes a
lot of sense) and that - b) Whether what you seem to infer about the
clean/quick client implementation bit is actually true (I would say
that in fact it is quite complicated, over-engineered, time consuming,
error prone, etc).
DUML restores and respects all of those reasons that we went to the
browser in the first place (see above) and does so with very simple
and intuitive mechanisms.
Navigation:
[Reply to this message]
|