Re: MVC philosopy question
David Sharp wrote:
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.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>