OO and RDBMS design decision
Rich
information about a basic computer (ie serial number, make, model), and
there are other tables such as one that relates the serial number to a
network name, and another that relates the serial number to an employee
payroll number (for computer allocation), and then an employee table that
contains (payroll number, name).
Is it better to have one class representing one table (DAO), and then
another class that retrieves the necessary information from various tables
to build my object? - so ComputerFactory would request information from
ComputerDAO, NetworkNamesDAO, AllocationDAO and EmployeeDAO. (The DAO
classes contain the actual SQL queries)
Or should I simply go for one class that does both jobs in that it queries
multiple tables to build my object? So ComputerFactoryDAO would create and
return Computer objects after querying all the tables.
On the one hand the first option seems more versatile in that I could reuse
the DAO classes for other queries. On the other hand the second option is
simpler.
I would appreciate some thoughts on this.
Best regards,
Rich.
Daniel Parker
news:twgt2xdq2kx$.hphqweokexif$.dlg@40tude.net...
> Say for example I have a Computer class has a table that contains the
> information about a basic computer (ie serial number, make, model), and
> there are other tables such as one that relates the serial number to a
> network name, and another that relates the serial number to an employee
> payroll number (for computer allocation), and then an employee table that
> contains (payroll number, name).
>
> Is it better to have one class representing one table (DAO), and then
> another class that retrieves the necessary information from various tables
> to build my object?
In general, no. The rules for partioning data into tables (normalization,
etc.) are different than the guidelines for encapsulating data in objects.
A one-to-one mapping doesn't normally make sense in terms of the semantics
of the objects.
> Or should I simply go for one class that does both jobs in that it queries
> multiple tables to build my object? So ComputerFactoryDAO would create and
> return Computer objects after querying all the tables.
>
In general, yes. This also allows you to refactor your tables and your
object layer independently, with the glue being the queries.
>
> On the one hand the first option seems more versatile in that I could
> reuse the DAO classes for other queries.
On the other hand, if it's important to you, you can create SQL statements
that are aggregates of parts you've defined somewhere.
> On the other hand the second option is simpler.
>
Not to mention more efficient.
Regards,
Daniel Parker
Kav
"Daniel Parker" <danielaparker@spam?nothanks.sympatico.ca> wrote in message
news:g6qJe.175$6d4....@news20.bellglobal.com...
Thank you very much, I didn't want to go running off down the wrong route!
As it was I allready had somewhat before it dawned on me things could get
complicated fast.
H. S. Lahman
> Say for example I have a Computer class has a table that contains the
> information about a basic computer (ie serial number, make, model), and
> there are other tables such as one that relates the serial number to a
> network name, and another that relates the serial number to an employee
> payroll number (for computer allocation), and then an employee table that
> contains (payroll number, name).
>
> Is it better to have one class representing one table (DAO), and then
> another class that retrieves the necessary information from various tables
> to build my object? - so ComputerFactory would request information from
> ComputerDAO, NetworkNamesDAO, AllocationDAO and EmployeeDAO. (The DAO
> classes contain the actual SQL queries)
Unless your application is pure CRUD/USER processing, the problem you
are solving for the customer is quite different than the problem of data
storage in an RDBMS. So solve the customer problem first and then
decide how to get the attribute data and relationships out of the RDB.
Then relegate the RDB access to a subsystem or layer and provide an
interface to it that is expressed in terms of the problem solution's
needs. That RDB access subsystem then exists to map the interface
requests into the RDM paradigm and the access infrastructure (e.g., SQL
queries) in hand. [My blog has a category devoted to relational mapping
and another for application partitioning that may be of interest.]
>
> Or should I simply go for one class that does both jobs in that it queries
> multiple tables to build my object? So ComputerFactoryDAO would create and
> return Computer objects after querying all the tables.
It is conventional to isolate instantiation of objects and relationships
to factory-like objects. That's because the rules and policies for
instantiation, referential integrity, etc. are usually quite different
than those for collaboration during the problem solution. (They also
commonly need to be executed only once for several collaboration
navigations.)
Where the factory object gets the information it needs to do that
instantiation is another question. Presumably it ultimately gets the
information from the RDB access subsystem or layer. If the only reason
one needs those indexing tables is to instantiate relationships and
objects, then it is probably fair to keep the DAO objects in the RDB
access subsystem/layer in the most convenient form for access. The
factory then queries the subsystem/layer for the information it needs in
the form most efficient for it to do its thing, which will probably be a
single request for multiple data elements.
> On the one hand the first option seems more versatile in that I could reuse
> the DAO classes for other queries. On the other hand the second option is
> simpler.
The first option (separating RDB access from problem solution) is,
indeed, more versatile and allows one to manage complexity better (e.g.,
optimizations for joins, caches, etc. that are specific to the RDB can
be encapsulated in the RDB access subsystem/layer so that any changes
to to the database or optimization strategies are transparent to the
problem solution. The second option (using a single god object to do
everything) will generally be more difficult to maintain when schemas
and optimization strategies change.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH
Mark Nicholls
Daniel Parker wrote:
> "Rich" <f...@h.com.net> wrote in message
> news:twgt2xdq2kx$.hphqweokexif$.dlg@40tude.net...
> > Say for example I have a Computer class has a table that contains the
> > information about a basic computer (ie serial number, make, model), and
> > there are other tables such as one that relates the serial number to a
> > network name, and another that relates the serial number to an employee
> > payroll number (for computer allocation), and then an employee table that
> > contains (payroll number, name).
> >
> > Is it better to have one class representing one table (DAO), and then
> > another class that retrieves the necessary information from various tables
> > to build my object?
>
> In general, no. The rules for partioning data into tables (normalization,
> etc.) are different than the guidelines for encapsulating data in objects.
> A one-to-one mapping doesn't normally make sense in terms of the semantics
> of the objects.
For small to medium systems I would tend to say yes. For large systems
I actually don't know, I've experimented with several styles and never
been happy with any.
I actually think the answer is usually dictated by technology, i.e.
microsoft tend to push the table data gateway model.
In fact I try to impose a 1:1 mapping in order to keep it all as simple
as possible.
>
> > Or should I simply go for one class that does both jobs in that it queries
> > multiple tables to build my object? So ComputerFactoryDAO would create and
> > return Computer objects after querying all the tables.
> >
> In general, yes. This also allows you to refactor your tables and your
> object layer independently, with the glue being the queries.
Something requires multiple tables I would consider the denormalised
join of those tables to be a table and write a table data gateway into
that.
> >
> > On the one hand the first option seems more versatile in that I could
> > reuse the DAO classes for other queries.
>
> On the other hand, if it's important to you, you can create SQL statements
> that are aggregates of parts you've defined somewhere.
I don't understand this.
>
> > On the other hand the second option is simpler.
> >
> Not to mention more efficient.
>
Is it simpler?
Alvin Ryder
> Say for example I have a Computer class has a table that contains the
> information about a basic computer (ie serial number, make, model), and
> there are other tables such as one that relates the serial number to a
> network name, and another that relates the serial number to an employee
> payroll number (for computer allocation), and then an employee table that
> contains (payroll number, name).
>
> Is it better to have one class representing one table (DAO), and then
> another class that retrieves the necessary information from various tables
> to build my object? - so ComputerFactory would request information from
> ComputerDAO, NetworkNamesDAO, AllocationDAO and EmployeeDAO. (The DAO
> classes contain the actual SQL queries)
>
> Or should I simply go for one class that does both jobs in that it queries
> multiple tables to build my object? So ComputerFactoryDAO would create and
> return Computer objects after querying all the tables.
>
I would keep separate things separate, for example Computer and
Employee are not directly related so I would not put Employee stuff in
Computer or Computer stuff in Employee. Later on, if your model
requires a relationship between them I'd have a separate class that
mixes things together, EmployeeComputerDAO, ComputerFactoryDAO or
whatever. This approach results in higher degree of modularity.
> On the one hand the first option seems more versatile in that I could reuse
> the DAO classes for other queries. On the other hand the second option is
> simpler.
>
Either way, you still end up with more or less the same code, it's only
a question of where do you put that code and what dependencies will
arise as a result of those decisions.
> I would appreciate some thoughts on this.
>
> Best regards,
> Rich.
Cheers.