velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Newton <d...@solaraccess.com>
Subject RE: Velocity + Database [long]
Date Thu, 07 Aug 2003 17:06:00 GMT
On Thu, 2003-08-07 at 12:32, Aaron Freeman wrote:
> 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.

I'm currently using a system that uses an XML file to define our
database tables. The database build and java class generation is
automagic. Unless the model requires non-generic handling of new fields,
tables, etc. I rarely have to code anything.

If the info needs exposure on the presentation layer then the page
designer will be involved anyway. If it's simple form-type stuff then it
should stay in the realm of the page designer; if it's more complicated
than that then I don't see how it would be avoidable under any MVC
scenario.

But if it is, I wanna know how, dangit, 'cuz that'd be useful. 

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

I'm not sure what this means--I store both objects and plain old data in
the database (well, that's I'm using for persistence right now, anyway.)
What do you mean by having objects reside in the database?

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

I don't know what you mean by being "locked into java objects only" (MVC
is a way, not a platform) but... to me it sounds like this is a semantic
point... So the SQL object is "really" a java object with SQL that talks
to an SQL database--what's the difference?

What does the SQL object look like/do?

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

I need to see an example of what you mean. So far it just sounds like
you want to be able to embed SQL stuff on a page. But the point of MVC
is to avoid that.

Obviously I'm missing what you're saying; sorry :(

Dave



Mime
View raw message