Re: Scalability VS Performance
From: Alok Jain (alokj_at_renewal-iis.com)
Date: 05/25/04
- Next message: David Browne: "Re: Scalability VS Performance"
- Previous message: William Ryan eMVP: "Re: Sql Server 2000 slow"
- In reply to: David Browne: "Re: Scalability VS Performance"
- Next in thread: David Browne: "Re: Scalability VS Performance"
- Reply: David Browne: "Re: Scalability VS Performance"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 25 May 2004 13:48:04 +0530
> This is a common problem, but it's really a database problem more than
> an OO problem. From the OO point of view you use Approach 1, period.
> A common approach here is to have a separate data source for each
> subclass you support. So a Task instance is populated by "select *
> from task", and WorkOrderTask is populated by "select * from
> WorkOrderTask". Where WorkOrderTask is a view which joins the main
> task table to the table containing the additional columns for
> WorkOrderTask.
Above solves the problem of referencing the base class (Task) specific
database fields in the derived (WorkOrderTask) class and this is also one
database call. But there is one more issue, now when we have the results of
the database call in derived (WorkOrderTask) class, what we will do with the
values which are specific to the base class? If we write code in the derived
class to set the base class attributes then this will break the
encapsulation for base class and this also enforces a high dependency on the
base class, whenever any base class member changes . Derived class will also
require changes (not a good approach).
In this scenario we can write a method in the base class
(setAttributes(DataReader dr) which can set its attributes. What you suggest
here?
Thanks again
Alok
"David Browne" <davidbaxterbrowne no potted meat@hotmail.com> wrote in
message news:uNWxRQaQEHA.1048@tk2msftngp13.phx.gbl...
>
> "Alok Jain" <alokj@renewal-iis.com> wrote in message
> news:ukTf0HZQEHA.3532@TK2MSFTNGP12.phx.gbl...
> > This is a design / inheritance qus.
> > I have class Task.
> > This is a base class for some specific tasks
> >
>
> . . .
>
> > Approach 1
> > I have to make 2 database calls.
> >
> > Approach 2
> > If theres some change in base class I need to take care of these in all
> the
> > derived classes as well.
> > Whereas, Approach 1 is advantageous here as by modifying only the
> > Task.GetDetails funciton ( this is the base class ) function i have all
> the
> > values and i do not need to touch the derived classes.
> >
> >
> >
> > Was thinking this might be a very common problem, so perhaps many of
might
> > be able to guide me on the approach i must take here. Perhaps anything
> other
> > then the two i have talked about.
> >
>
> This is a common problem, but it's really a database problem more than an
OO
> problem. From the OO point of view you use Approach 1, period. A common
> approach here is to have a seperate datasource for each subclass you
> support. So a Task instance is populated by "select * from task", and
> WorkOrderTask is populated by "select * from WorkOrderTask". Where
> WorkOrderTask is a view which joins the main task table to the table
> containing the additional columns for WorkOrderTask.
>
> David
>
>
- Next message: David Browne: "Re: Scalability VS Performance"
- Previous message: William Ryan eMVP: "Re: Sql Server 2000 slow"
- In reply to: David Browne: "Re: Scalability VS Performance"
- Next in thread: David Browne: "Re: Scalability VS Performance"
- Reply: David Browne: "Re: Scalability VS Performance"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|