Re: MVC design advice for a simple GUI app.



Sorry, I actually meant to say 'knowledge' burden and not
computational/processing burden, and here's the reason why I (not
necessarily correctly) thought so: The Model is supposed to represent
all of application's domain logic. The knowledge of the how's and the
why's of coordinate-space transformations, I thought (and to some
extent still think), falls more under domain logic than under
presentation logic. Also, if more views get added in future, this
knowledge would not need to be replicated in the new views but could be
reused from the Model.


I would automatically put this knowledge of the viewport in the view,
because it's the view. Replicating the knowledge in a new view is
probably not something you should worry about at this point. And
anyway, why does a new view have to be graphical? A different view
might just be a list of text items. I don't know the details of your
app, so I can only speculate.

I borrowed the term 'GUI-state model' fromhttp://java.sun.com/products/jfc/tsc/articles/architecture/where it's
being contrasted with 'application data model'.

If my application allows a rich set of GUI customizations and
preferences, I thought it would be wise not to lump this GUI-state
together with the 'core', 'non-visual' application model. An example
of this would be, toolbox size/placement/configuration, button size,
view locations/sizes, various font and color choices, etc.

OK, so you want to save user preferences such as toolbar layout, window
position, etc. That is definitely separate. Something you might want
to store in a preferences file.


Even in a Graphics application such as this one, I tend to see the
Model as the application in its entirety sans the application's views
and controllers. I think a good test of my design would be if I could
neatly drive the application (the model) via a script file (the
controller) and have results logged to a file in some form (the view)!
For example, when drawing a freehand area via a script, I could assert
the correctness of my area calculations even though I may not see
anything visual. Another test of the soundness of my MVC design, I
think, would be if I could drive the application via a script but with
graphical views present this time.

Absolutely!

Given this, should I have 2 models -- one visual (for
maintaining/mediating the overall state of the GUI), and the other
non-visual (for holding the non-graphical counterparts of lines, rects,
and other things)?

I hesitate calling user preferences a "model", but OK. Yes.

The more I'm thinking these issues, the more philosophical (confused?)
I'm getting it seems. For example, when designing the class for the
non-graphical Line, should I also store line-thickness, -color, -style
(dashed, solid, etc)... along with the 2 end-points?

This all depends on the purpose of your app. If it's a drawing
application, I would say absolutely, since line thickness, color, and
style are all attributes of a graphical primitive in the drawing. You
ought to look at some other graphical file formats to see how they do
it.

If yes,
- this Line class ceases to be a purely non-graphical entity.

I'm having trouble seeing how a class called "Line" is going to be
non-graphical, but it depends on your app. And also, you'll probably
want to split out those attributes from before into a separate class,
such as "StrokeFormat" or "LineFormat", etc.

- during automated regression testing of Line's length, I'll be forced
to supply dummy values for these other graphical attributes.

This all depends on your strategy for testing. And anyway, can't you
have default values for StrokeFormat?

+ all Line's attributes conveniently stay in one place.

Yes, again, depends on your app whether or not this is good.

If no,
+ this Line class becomes a pure, non-graphical entity

Still depends on your app..

+ during automated regression testing of Line's length, I need to
worry about only the mathematical attributes (ie, the 2 end-points)

OK, but I'd probably have that kind of functionality in a separate
geometry subsystem.

- I have to separately keep track of a Line object's graphical
attributes and summon them during rendering and serialization to disk.

Not sure why this is a problem.

.