MVC philosopy question

[David Sharp]

When you're constructing an application, do you envision the model as a
persistent monolithic entity that represents the current application
state? Or do you envision the model as an transient entity, related
only to the current page (resulting in one model per page).

Until recently, I've always thought of the model as the current overall
application state (as expressed by the database), and the web pages were
all simply methods of manipulating that state.

More recently, however I've come to realize that there is some merit to
thinking of the model as being a transient entity that exists simply to
move data back and forth between the controller, sort of a form backing
bean on steroids.

In the first case, the model exists as a set of interrelated data
records in the database. In the second, the model is created by the
controller to communicate with the view.

So I'm looking for some input from some programmers as to how they
envision the "model" in an MVC application. Maybe there is yet another
way of defining it that I haven't thought of.

Anyhow, I appreciate any feedback.

Dave

 

[Stefan Ram]

When you're constructing an application, do you envision the
model as a persistent monolithic entity that represents the
current application state?

To me, it is more like a »layer«: A set of objects.

The model of an individual button might be just a
single object, but the whole application usually
has more than just on object in the model.

Or do you envision the model as an transient entity, related
only to the current page (resulting in one model per page).

For an application, in general, the term »page« or »current
page«, has no meaning. Some applications might have entities
called »pages«.

Until recently, I've always thought of the model as the current
overall application state (as expressed by the database), and
the web pages were all simply methods of manipulating that
state.

In the general case, an application is not necessarily related
to web pages. Although, there might be some applications, also
known as »web applications« that are related to web pages.

In the first case, the model exists as a set of interrelated
data records in the database.

In the general case, an application does not necessarily
use a »data base«. Some applications might do so.

 

[David Sharp]

My apologies. I should have been more clear. My question pertains to
Web Applications.

Dave

 

[Daniele Futtorovic]

My apologies. I should have been more clear. My question pertains to
Web Applications.

Dave

Web applications are somewhat of a special case wrt MVC, due to the
network barrier and stateless HTTP. In web applications, with tools like
Javascript et al., you effectively transfer some part of the controlling
to the client side. For that controlling to be more effective and
powelful, you end up backing it with parts of the model -- on the client
side, and thus necessarily bound to a page (if we discount cookies).

 

[Daniele Futtorovic]

My apologies. I should have been more clear. My question pertains
to Web Applications.

Dave

Sorry for the precocious post -- bloody crtl-enter.

Web applications are somewhat of a special case wrt MVC, due to the
network barrier and stateless HTTP. In web applications, with tools like
JavaScript et al., you effectively transfer some part of the controlling
to the client side. For that controlling to be more effective and
powerful, you end up backing it with parts of the model -- on the client
side, and thus necessarily bound to a page (if we discount cookies).
I think that's where your confusion arises from. You don't have that
situation in desktop applications.

DF.

 

[Lew]

Sorry for the precocious post -- bloody crtl-enter.

Web applications are somewhat of a special case wrt MVC, due to the
network barrier and stateless HTTP. In web applications, with tools like
JavaScript et al., you effectively transfer some part of the controlling
to the client side. For that controlling to be more effective and
powerful, you end up backing it with parts of the model -- on the client
side, and thus necessarily bound to a page (if we discount cookies).
I think that's where your confusion arises from. You don't have that
situation in desktop applications.

In its full panoply of glory the MVC pattern admits of multiple controllers.
That "backing bean" of which you spoke is called the "controller" in Java
Server Faces (JSF).

The notion of having one or multiple *models* is sort of like asking if that
big bowl of Jello (r) in the fridge is one Jello, versus when you serve it to
the family in 4.5 bowls, is that 4.5 Jellos?

How you cut it is arbitrary - choose a taxonomy that supports development and
maintenance the best.

 

[Daniele Futtorovic]

In its full panoply of glory the MVC pattern admits of multiple
controllers. That "backing bean" of which you spoke is called the
"controller" in Java Server Faces (JSF).

The notion of having one or multiple *models* is sort of like asking
if that big bowl of Jello (r) in the fridge is one Jello, versus when
you serve it to the family in 4.5 bowls, is that 4.5 Jellos?

The proof of the pudding is in the fridge?

How you cut it is arbitrary - choose a taxonomy that supports
development and maintenance the best.

Yup. I was trying to propose an explanation as to how the questions the
OP was asking might have arisen from some constraints specific to web
applications, but were not inherent to the MVC pattern as such.

DF.

 

[Hal Rosser]

When you're constructing an application, do you envision the model as a
persistent monolithic entity that represents the current application
state? Or do you envision the model as an transient entity, related only
to the current page (resulting in one model per page).

Until recently, I've always thought of the model as the current overall
application state (as expressed by the database), and the web pages were
all simply methods of manipulating that state.

More recently, however I've come to realize that there is some merit to
thinking of the model as being a transient entity that exists simply to
move data back and forth between the controller, sort of a form backing
bean on steroids.

In the first case, the model exists as a set of interrelated data records
in the database. In the second, the model is created by the controller to
communicate with the view.

So I'm looking for some input from some programmers as to how they
envision the "model" in an MVC application. Maybe there is yet another
way of defining it that I haven't thought of.

Anyhow, I appreciate any feedback.

Dave

The Model would be your business classes.
For instance you may have a class that you use for retreiving objects (from
a record of) a relational database - that class could be useful in a regular
plain-ole command-line program - OR - a GUI program - OR a web application.
Its a stand-alone useful class that helps you do business. You could code it
as a bean.

 

[Mark Space]

The proof of the pudding is in the fridge?

Not anymore. Uh... sorry. Didn't know you were saving that.

 

[Daniele Futtorovic]

Not anymore. Uh... sorry. Didn't know you were saving that.

What's in its stomachsess... we wonders, oh yess, we wonderss... Thief!
Thief! We hates it! We hates it!

 

[Daniel Pitts]

When you're constructing an application, do you envision the model as a
persistent monolithic entity that represents the current application
state? Or do you envision the model as an transient entity, related
only to the current page (resulting in one model per page).

It depends. Often there are several layers to this, I'll expand below.

Until recently, I've always thought of the model as the current overall
application state (as expressed by the database), and the web pages were
all simply methods of manipulating that state. That is part of the model.

More recently, however I've come to realize that there is some merit to
thinking of the model as being a transient entity that exists simply to
move data back and forth between the controller, sort of a form backing
bean on steroids.

In the first case, the model exists as a set of interrelated data
records in the database. In the second, the model is created by the
controller to communicate with the view.

So I'm looking for some input from some programmers as to how they
envision the "model" in an MVC application. Maybe there is yet another
way of defining it that I haven't thought of.

Anyhow, I appreciate any feedback.

Dave

"State" gets more complicated in web applications. You have several
states to deal with in a web application.
You have persistent state (database), session state, request state, and
client-side state. To make things worse, you can multiple "versions" of
each of those states. You need some way to manage the discrepancies in
the various states. Often, a useful approach is often to think of each
layer as its own model. Even if they are similar, they are in a
different place in the stack.

So, there are multiple models to deal with. They should all be aware of
there own business rules and logic. If there are business rules that
span all (or most) of them, then it may be useful to factor those rules
out.

Further complication comes from the fact that client-side information is
usually in a form that is fundamentally different than it is on the
server side -- form fields or JavaScript strings/numbers versus Java
objects.

Now, think about this. In any GUI application, the components
themselves may have a complete MVC of there own (JButton for instance)
that is distinct from the business MVC. It would be folly to attempt to
create every aspect of your application with a single MVC to do
everything. The benefit of OOP is the ability to think about one object
at a time without thinking about every single part of the rest of the
system.

Obviously, you have to think about the overall system at some level, but
if you can break that up into "byte" size pieces (sorry, bad pun), then
you can deal with complex systems in a manageable way.