velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Freeman" <>
Subject RE: Velocity + Database [long]
Date Thu, 07 Aug 2003 16:32:21 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.

Great points!

> 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.

I don't think organizations necessarily confuse the database with the model.
They are typically trying to generate a robust schema that has proper
business rules in order to maintain stability without relying on another
application such as Java, VB, whatever--I don't even think MVC is in their
mind when the ERD is drafted up.  The end result is that the database ends
up being a great representation of the final model, because it incorporates
the same business rules that the model will end up supporting. For example,
a checking account entity has a foreign key reference to a user account.
The implementation of this model will also require the person to have a user
account before they can review a checking account.

> 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.

What is worse is that current MVC implementations require you to recompile
Java when the database changes!  That is much more painful because now a
simple database change causes the page designer _and_ a Java programmer to
be involved.

The same stability issue arises with the JVM as it does with the database.
If the database is properly designed then all will be ok.  If the Java
objects are properly designed then all will be ok. The same problem arises
either way.

Current MVC implementations require that the objects referred to above
always reside within an application, without having the flexibility to allow
the objects to reside in the database.  IMHO, this is not a good thing . . .
its a bias toward a particular technology.

> 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.

To satisfy this, why can't the "adaptor" be an SQL "object" that interfaces
with the underlying entity as opposed to a Java object that has embedded SQL
that interfaces with the underlying entity?  Then MVC is not locked into
Java objects only.

> 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.

Agreed.  Its just too painful to require your Java team to be involved with
database changes that shouldn't have to involve them.  Again, an SQL
"object" would allow the SQL programmer and page designer to get the job
done as well.

> 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!

Agreed, however the DDL _and_ the DML need to be decoupled.  The DML is
really the adaptor between the page and the database so it should be
referenced via a VTL tag much like a Java object would, but it could still
be placed in a text file somewhere for easy editting by the SQL programmer,
without having to involve a Java programmer.

Am I completely off base here?  I don't think this is violating your rules,
just expanding on your adaptor concept.

Aaron Freeman
Layer-Z, Inc.
Phone: (316) 722-8808
Fax: (215) 895-9813

View raw message