Object models, Domain models, Application models, and MVC? 
Author Message
 Object models, Domain models, Application models, and MVC?


Quote:
>An "application model" in Smalltalk jargon is a model that
>supports interaction behavior, and sits essentially between the
>business model (the implementation of the conceptual domain
>model) and the user interface.  It is not uncommon for the
>business model and the application model to be merged, unless
>there is the intent for the business model to be reused, or in
>some fashion shared, either among multiple applications, via
>a database, or whatever.

It may not be uncommon for the two models to be merged, but I think it would
be a tremendously bad idea. Separating the GUI from the interface is a
pretty fundamental concept, and if you don't have the application model
layer you're almost certainly going to wind up hacking UI behaviour into the
domain model. You can pretend the domain is isolated from the GUI when you write
   self
     changed: #pleaseUpdateListNumber12InTheGUINow
     with: listOfWidgetNames
but it's not.
--
Alan Knight                     | The Object People

613.225.8812(v) 613.225.5943(f) | http://www.*-*-*.com/

If putting more people on a late project makes it later then
let's try removing people.



Sat, 03 Apr 1999 03:00:00 GMT  
 Object models, Domain models, Application models, and MVC?

Quote:

> It may not be uncommon for the two models to be merged, but I think it
would
> be a tremendously bad idea. Separating the GUI from the interface is a
> pretty fundamental concept, and if you don't have the application model
> layer you're almost certainly going to wind up hacking UI behaviour into
the
> domain model.

You're right, and I think what I said before was exceedingly
poorly stated, to the point of being clearly wrong.  Thanks
for the correction.  

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
William D. Gooch
Icon Computing

Texas liaison for the International Programmers Guild
For info on IPG, see http://www.ipgnet.com/ipghome.htm
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



Sat, 03 Apr 1999 03:00:00 GMT  
 Object models, Domain models, Application models, and MVC?

Quote:


>...
>>Is a domain model the same as the object model? Is it the model of the MVC
>>(Model-View-Controller).
>...
>>And then what really set me off, in the Sep 96 Object Magazine issue
>>(several articles on ST; you should all read it), Brown and Whitenack
>>propose a 4-layer approach. From outside-in: (1) View layer, (2)
>>Application Model layer, (3) Domain Model layer, (4) Instrastructure
>>layer. Sounds great, but what is the difference between the application
>>model and the domain model?
>...
>>And its this pattern that is bothering me. Who generates the events? This
>>may be an incorrect impression, but the way I understand the Model in the
>>MVC is that it is supposed to be passive. It does not control
>>functionality or decide what to do. It just sits there and responds to
>>gets and sets.
>...

>It sounds like there's some basic terminology confusion going on here, not
>surprising given the variety of ways in which the terminology is used. I'll
>define what I think is the way these terms are generally used in the
>Smalltalk community, which probably corresponds to the Brown-Whitenack article.

Part of the difficulty, as you note, is the grave equivocation over
the word "model" in Smalltalk literature.  This seems to have
been porrly understood (at best) by ParcPlace; it has been confused
rather than clarified by their xxWorks packages.

Quote:
>Domain Model, Business Model: The objects that make up the basic
>functionality of your application, and which have nothing to do with the
>GUI. The model objects defeinitely do NOT just sit there and respond to get
>and sets. They contain the essential behaviour of the system.

True enough -- although many many users would be horrified
to hear the GUI dismissed as "non-essential";

Quote:
>View: The GUI components. e.g. a ListBox, Label, Text Editor, etc.

>Application Model: The object which mediates between the domain model and
>the GUI components. The presence of this layer allows the GUI components
>(views) to be completely generic. A stereotypical responsibility for this
>type of object might be to disable the properties button when nothing is
>selected in the list. The term ViewManager or ApplicationCoordinator are
>also likely to be used in this way. All of these come from class names in
>various GUI frameworks. I think this is what you are calling a Controller.

It is here that I must take slight exception to your presentation:
The Application Model does much more than  mediate betweend
a GUI Component (or set thereof) and a domain model.
If we had a simple world, where GUI's corresponded one-to-one with
domain models, we would have no need for an Application Model.
However, we often need to view 'data' gathered/selected from a
related set of domain objects, for presentation in a single view.
(One need only think of name/address/invoice/account relationships
to see the issue here.)
The Application Model is, in a sense, a "super" model -- it gathers
and co-relates a set of domain objects into a single object model for
the purposes of a GUI.
This is incredibly important, and essentially obscured by the MVC
approach, and its associated zealots.

[snip]

Quote:
>If I understand what you are saying, I completely disagree. GUI's are
>subject to random and arbitrary change at the whim of the end user. This
>does not generally reflect corresponding change in the model.

But these changes are not random and rarely "whim driven".  They
may *look* that way, but as we are not end users in the relevant
domain, our perspective is irrelevant at best.
More to the point, these changes required of the GUI often imply
corresonding changes to the Application Model.  Application Models
are not particularly robust or reusable.  Domain objects, on
the other hand, are rarely impacted by these changes, and are
relatively robust and stable.
But the Application Model is crucial for coordinating the set of related
objects being viewed; changes in the viewing requirements will
percolate back into changes in the ApplicationModel.  It may be,
in fact, that the views and controllers are stable and unchanging,
and that the locus of change is the Application Model itself.
A certain sort of MVC heresy, but a useful perspective.
The real trick is to stay very very clear on the fact that "model"
is an inherently ambiguous and equivocal term in OO programming.

Bill Felton
Gryfon Technologies
(503) 644-8820



Sun, 04 Apr 1999 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Object models, Domain models, Application models, and MVC?

2. Data Modeling/Object Modeling (was Re: [OT] RE: help -- persuade my boss to adopt ruby)

3. setting the model of a TreePresenter in Dialog>>model:

4. Should ReferenceView<<model return referee model?

5. c model convert to verilog/VHDl model

6. Models Models?

7. I2C Model Synthesizable Model

8. How to model the transmission gate in Verilog without using tran (Behaviour model)

9. PLI model vs. Verilog model

10. C model in model tech.

11. MODEL: Need 68030 model.

12. a 3D model search engine, currently about 20,000 models indexed

 

 
Powered by phpBB® Forum Software