Database Driven Object Factory - Am I Nuts?

[Jeff S]

I'm relatively new to non trivial OOP programming and recently stumbled
across the idea of Factory classes that can create objects at runtime. I
know we can hard-code class definitions for use by our Factory classes...
just wondering if it's a common practice to drive class definitions from a
database. Somehow the possibility of doing this seems both very cool (that
it may be possible) and very dangerous ("just because you can doesn't mean
you should").

So, how would I go about automating the construction of runtime objects -
and have the definition of each object determined at runtime from a database
(in whole or in part).

Specifically (and for example) say I want to create Person objects at
runtime. Each Person has a FirstName and LastName property. Somewhere in a
database I store the fact that Person objects have a FirstName and LastName
property. Then tomorrow I want to cause Person objects to additionally have
a MiddleName property. What I want is to simply be able to update the
database and - Bingo! - the Person objects now all have a MiddleName
property.

Am I nuts or is this a reasonable thing to be attempting?

Thoughts? Opinions? Perspective on *how* Factory classes most reasonably
create runtime objects?

Thanks!

[AlexDP]

This is actually an idea that has occured to me too and I am currently
working on a way to do this. I'd like to hear any comments on your idea.

"Jeff S" wrote:

I'm relatively new to non trivial OOP programming and recently stumbled
across the idea of Factory classes that can create objects at runtime. I
know we can hard-code class definitions for use by our Factory classes...
just wondering if it's a common practice to drive class definitions from a
database. Somehow the possibility of doing this seems both very cool (that
it may be possible) and very dangerous ("just because you can doesn't mean
you should").

So, how would I go about automating the construction of runtime objects -
and have the definition of each object determined at runtime from a database
(in whole or in part).

Specifically (and for example) say I want to create Person objects at
runtime. Each Person has a FirstName and LastName property. Somewhere in a
database I store the fact that Person objects have a FirstName and LastName
property. Then tomorrow I want to cause Person objects to additionally have
a MiddleName property. What I want is to simply be able to update the
database and - Bingo! - the Person objects now all have a MiddleName
property.

Am I nuts or is this a reasonable thing to be attempting?

Thoughts? Opinions? Perspective on *how* Factory classes most reasonably
create runtime objects?

Thanks!

[Peter Bromberg [C# MVP]]

Jeff,
this really all boils down to Object Relational Mapping (ORM for short).
There must be two dozen ORM frameworks out there now, many are open-source or
have free versions, and some will dynamically query your data store and do
what you are looking for.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"Jeff S" wrote:

I'm relatively new to non trivial OOP programming and recently stumbled
across the idea of Factory classes that can create objects at runtime. I
know we can hard-code class definitions for use by our Factory classes...
just wondering if it's a common practice to drive class definitions from a
database. Somehow the possibility of doing this seems both very cool (that
it may be possible) and very dangerous ("just because you can doesn't mean
you should").

So, how would I go about automating the construction of runtime objects -
and have the definition of each object determined at runtime from a database
(in whole or in part).

Specifically (and for example) say I want to create Person objects at
runtime. Each Person has a FirstName and LastName property. Somewhere in a
database I store the fact that Person objects have a FirstName and LastName
property. Then tomorrow I want to cause Person objects to additionally have
a MiddleName property. What I want is to simply be able to update the
database and - Bingo! - the Person objects now all have a MiddleName
property.

Am I nuts or is this a reasonable thing to be attempting?

Thoughts? Opinions? Perspective on *how* Factory classes most reasonably
create runtime objects?

Thanks!

[Steven Nagy]

We use a code generator that creates classes based on our database
tables.
We use SQLDMO for this. We even capture relationships between tables to
instantiate child objects.
At run time, we use reflection in our DAL to analyse our objects and
execute relevant queries.

Hope this helps.

[Jeff S]

Thanks, and yes, it helps to know this sort of thing is going on.

What has been your experience with runtime performance with reflection? It
seems that this kind of flexability would come at some price.

-J
"Steven Nagy" <le*********@hotmail.com> wrote in message
news:11*********************@g47g2000cwa.googlegro ups.com...

We use a code generator that creates classes based on our database
tables.
We use SQLDMO for this. We even capture relationships between tables to
instantiate child objects.
At run time, we use reflection in our DAL to analyse our objects and
execute relevant queries.

Hope this helps.

[Steven Nagy]

Its not too bad really... the performance drops in other areas, such as
the multiple data queries to support nested objects and so on.
Trying to overcome this currently.

Most our projects that use this technology are windows apps, where the
database is on the same network. We have about 20-40 database hits per
second in some of our apps, and reflection seems to cope fine.

[Daniel]

I dont use factory classes myself so apoaogies if this comes across
ignorant. But why would you want to run any objects through a databse? First
the IO innvolved for every access to create the object is going to be more
overhead, and secondly to add something such as in your example would be
just as simple, if not quicker due to no needed sql, to add to the class
itself?
"Jeff S" <[e-mail]> wrote in message
news:Om**************@TK2MSFTNGP15.phx.gbl...

I'm relatively new to non trivial OOP programming and recently stumbled
across the idea of Factory classes that can create objects at runtime. I
know we can hard-code class definitions for use by our Factory classes...
just wondering if it's a common practice to drive class definitions from a
database. Somehow the possibility of doing this seems both very cool (that
it may be possible) and very dangerous ("just because you can doesn't mean
you should").

So, how would I go about automating the construction of runtime objects -
and have the definition of each object determined at runtime from a
database (in whole or in part).

Specifically (and for example) say I want to create Person objects at
runtime. Each Person has a FirstName and LastName property. Somewhere in a
database I store the fact that Person objects have a FirstName and
LastName property. Then tomorrow I want to cause Person objects to
additionally have a MiddleName property. What I want is to simply be able
to update the database and - Bingo! - the Person objects now all have a
MiddleName property.

Am I nuts or is this a reasonable thing to be attempting?

Thoughts? Opinions? Perspective on *how* Factory classes most reasonably
create runtime objects?

Thanks!

[Steven Nagy]

Same argument could apply to datasets and datatables... well actually
it does.
Even MS admit the overhead involved with these classes.
However custom object factories usually run much better.
Still have to represent the data somehow, and strongly typed data is
more useful.