Thread: naked objects from stored procedures, interface generation

Hallo,

there exist many framework that 'backward' engineer from a programming
language to database to make the data persistent.
so: code >> db (generated)
eg. hibernate, turbogears many others

My question is, from db point of view, do we have such frameworks that
work the other way,
ie that forward engineer from a database to a user interface (web or
program),
maybe using the stored procedures available on the database (eg in the
same naked objects work)
so: exisiting db (possible + stored procedures) >> user interface (eg
crud or other)

mvg,
Wim

Hello

I know about one similar project - Garuda, but this project isn't open.

What it does:

* OOP - objects, properties, methods - not based on PostgreSQL OOP
* support of workflow - lifecycle for objects
* support of collection of objects

It was designed in plpgsql with special modules to PHP, where was
possible to work with Garuda objects like PHP objects.

Regards

Pavel Stehule


2010/12/23 Wim Bertels <wim.bertels@khleuven.be>:
> Hallo,
>
> there exist many framework that 'backward' engineer from a programming
> language to database to make the data persistent.
> so: code >> db (generated)
> eg. hibernate, turbogears many others
>
> My question is, from db point of view, do we have such frameworks that work
> the other way,
> ie that forward engineer from a database to a user interface (web or
> program),
> maybe using the stored procedures available on the database (eg in the same
> naked objects work)
> so: exisiting db (possible + stored procedures) >> user interface (eg crud
> or other)
>
> mvg,
> Wim
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

On 12/23/10 12:19 AM, Wim Bertels wrote:
> My question is, from db point of view, do we have such frameworks that
> work the other way,
> ie that forward engineer from a database to a user interface (web or
> program),
> maybe using the stored procedures available on the database (eg in the
> same naked objects work)
> so: exisiting db (possible + stored procedures) >> user interface (eg
> crud or other)

one database can serve many applications.

the database provides the persistent storage for the 'model' part of a
classic M-V-C system, and it can provide some to much of the 'model'
business logic, but its really not suitable for either the view or the
controller, those are better expressed in other domains