velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Husted <hus...@apache.org>
Subject Re: Velocity + Database [long]
Date Thu, 07 Aug 2003 13:52:44 GMT
The thing to keep in mind that Model in MVC does not actually refer to 
the database system, like JDBC. A database system is a mechanism by 
which we persist the Model.

The idea is that first we model the application's problem domain as 
objects. Objects that are persisted are often referred to as Entity 
Objects, but the Model can also include transient objects.

To persist the Model, we represent it as a series of queries that can be 
applied to a database schema. To visualize the Model, we represent it as 
a series of screens or pages that can be rendered to an output device. 
But neither the database nor the pages are the Model: they are different 
representations of the same Model.

What happens is that many organization put so much effort it modeling 
the problem domain as a database, we often forget that the database is 
not the Model, but merely one representation. The map is not the land.

In the rush to market, we have often taken shortcuts and let our page 
representations refer directly to the database representation. As long 
as the database is stable, this isn't a problem. But if the database 
changes, and there is nothing between the page and the database, then 
the pages need to change with it. Likewise, in this type of "model 1" 
arrangement, changes we want to make to the pages sometime imply making 
changes to the database.

In a true MVC implementation, there is a pure-object Application Model 
that mediates between the page model and the database model. 
Essentially, we end up with an adaptor between the page and the 
Application Model and another adaptor between the Application Model and 
the database.

This lets pages be pages and databases be databases. If one 
representation changes, we update its adaptor to the Application Model.

More importantly, decoupling the representations makes it easier to 
*test* the pages and the database independently of one another. The 
pages or the database can be tested directly against the Application 
Model, without having both running at the same time. We can also swap in 
a mock adaptor to test against a mock database or mock page.

Of course, coding a true Application Model and the adaptors to go with 
it is more work and not always justified by the scope of a project. But 
if the project is enterprise-grade, subject to change, and will be in 
service for many years, an explicit Application layer quickly pays 
dividends.

But, there are many, many environments where the database is stable and 
linking the page representation to the database representation is not 
such a bad thing. The vital issue is to get as many of the database 
implementations details out of the VTL as possible. This way, such 
details can be maintained by someone who understands the databases but 
not VTL, AND so that this information can be shared between VTL's. 
Apparently, VeloSurf is trying to do exactly that!

For larger, more dynamic applications, we are now seeing some good 
Object Relational Modeling (ORM) tools that provide the adaptor between 
the Application Model and the database representation. Hibernate 
<http://http://sourceforge.net/projects/hibernate> is my personal favorite.

But, sigh, I'm still looking for something that can "flatten" a rich 
object Model into a simple transfer object, so that nested objects look 
like top-level properties (Person.Address.Street -> Person.AddressStreet).

-Ted.


Claude Brisson wrote:

> Nathan wrote :
> 
> 
>>so, yeah, Velosurf already separates SQL from the templates (and in a clean,
>>simple way), but it doesn't separate Model *manipulation* from the View.
>>therein lies the MVC "no-no."  of course, if your application involves only
>>presentation (reports and whatnot), then just tell Velosurf to be read-only,
>>and you have a quick and easy way to expose your model to the view for
>>presentation.  my understanding is that that would be simple, quick, and
>>legitimate MVC.
> 
> 
> Good remarks, but since classes mapping database objects can be inherited, you can have
your $mypersistententity.delete() make
> anything you want, like generate an event in the framework instead of really deleting
the row from the db (which remains the default
> behaviour if not in read-only mode).
> 
> In fact, the aim of Velosurf is not to merge the View and Model layers, but to help to
expose (parts of) the Model into the View,
> which is more or less needed at some point.
> 
> In the next Velosurf release, I'll try to rewrite the docs so as to implicitely drive
users towards a better respect of the MVC
> principles.
> 
> CloD
> 
> ----- Original Message -----
> From: "Nathan Bubna" <nathan@esha.com>
> To: "Velocity Users List" <velocity-user@jakarta.apache.org>
> Sent: dimanche 27 juillet 2003 00:05
> Subject: Re: Velocity + Database
> 
> 
> 
>>Aaron Freeman said:
>>...
>>
>>>Ok, I think a very cool way to do what I was talking about, as well as
>>>accomplish better MVC practices is to add a new VTL directive called #query
>>>that would be placed inside of .vs (velocity SQL [only a best practice
>>>requirement]) files.
>>>
>>>For example inside of a file called user.vs you would have:
>>>#query ( name='getUsersByAge')
>>>SELECT username
>>>  FROM users
>>>WHERE age = #age
>>>         AND state = #state
>>>#end
>>>
>>>Then in your index.vm you might have:
>>><html>
>>><body>
>>>#foreach ($user in $getUsersByAge.username)
>>>$velocityCount: $user
>>>#end
>>></body>
>>></html>
>>
>>creating this would be a lot of work and would be not much different from
>>Velosurf.  frankly, i think Claude's system (defining the querys and entities
>>and whatnot in a separate xml file) is better than this would be, and his
>>system is already created.
>>
>>
>>>By separating the SQL into separate files, that really separates the SQL
>>>programming logic from the View logic, and it makes it very easy on the SQL
>>>programmer ... he doesn't need to know java.
>>
>>eh...  i guess i should be clearer.  Velosurf doesn't involve putting SQL in
>>templates, but it does have SQL*calls* directly exposed.  so in your template,
>>you would do things like $mypersistententity.delete().   in a more typical MVC
>>setup, you would not expose things like that to the template (or whatever view
>>technology you are using).  that sort of model manipulation would happen in
>>Java code (usually in business/model logic code that is called from an
>>*action* class of a framework like Struts or Turbine).
>>
>>so, yeah, Velosurf already separates SQL from the templates (and in a clean,
>>simple way), but it doesn't separate Model *manipulation* from the View.
>>therein lies the MVC "no-no."  of course, if your application involves only
>>presentation (reports and whatnot), then just tell Velosurf to be read-only,
>>and you have a quick and easy way to expose your model to the view for
>>presentation.  my understanding is that that would be simple, quick, and
>>legitimate MVC.
>>
>>Nathan Bubna
>>nathan@esha.com
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
> 
> 

-- 
Ted Husted,
   Junit in Action  - <http://www.manning.com/massol/>,
   Struts in Action - <http://husted.com/struts/book.html>,
   JSP Site Design  - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.



Mime
View raw message