|
|
Posted by Jerry Stuckle on 02/19/07 13:07
rpsetzer@yahoo.com wrote:
> I have to create a big web application and I was thinking of using a
> data layer. For each entity in the database, I'll define a class that
> maps the table structure, having sub-objects for each foreign key,
> having insert/delete/update methods, the usual deal. Yet, I am very
> concerned about performance. For example, there are lots of cases when
> I may just be needing the employee name. Yet using this model, I will
> have to instantiate an entire Employee class, which may have sub-
> objects and use lots of SELECT queries. I think this will be an
> important performance hit. What do you think? Ever did something like
> this? Is it worthy? Is there a better way? Should I give up creating
> the data layer?
>
I do objects in all my more complex sites. But I generally use business
objects - ones related to the job at hand. Any business object may be
related to a few columns in one table, most columns across multiple
tables, or anything in between.
And I may even use the same object, but have different fetch methods
which retrieve only partial data.
For instance, if I have:
table student
id int
name char(30)
other stuff
table class
id int
name char
instructor_id int
other stuff
table class_student
class_id int
student_id int
I might have a class which will retrieve all the student names, the
instructor name, day(s) and start/s for a single class, the room in
which it will be held, etc.. Alternatively, it might only retrieve a
count of the number of students in the class
If the data is getting more complex, I may add a pure data layer under
the business object layer, where I do have one table per object. But
this layer will also have multiple functions to allow me to retrieve
what I need, when I need it.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|