Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

OOP and Web application

OOP and Web application

OOP and Web application

Hi everyone,

I'm fairly well versed with OOP concepts and am now trying as much as possible to apply it when I design web-apps.

Problem I am facing though is scalability and performance.  I don't know which way to go...

Should I be making very simple, almost trivial object to perform basic task (which really add more complexity than anything) or full blown object.

Perhaps what I am asking would be more clear with an example.

Say a Customer object's instance

Customer have a collection of Address.

Now my application needs to display the first/last name of someone.

So some pseudo would look like this
person1 = new Customer(10340);
output(person1.getFirstName() + " " + person1.getLastName());

My issue is with the constructor, have called Customer() I would have loaded the address collection as well which isn't required in most cases.

What am I suppose to do in those case? Break down the "Customer" object? To me having real object simply doesn't scale well, I always end up fetching additional data which I don't need most of the time for trivial tasks.


RE: OOP and Web application

There are a couple ways to handle this.
1. if the number of addresses per customer is minimal (10) or less, then loading them every time isn't a huge overhead.
2. if your ORM/DAL has the concept of lazy loading then the tool will handle this on it's own. you don't have to worry about it.

I really love the combination of Adaptive Domain Models and Fetching Strategies. basically it looks like this


class Person : IHuman, IParent, IChild

HumanFetchingStrategy: IFetchingStrategy<IHuman>
   public ICriteria Filter(ICriteria criteria)
       return critiera.ModifyFetchingStrategies...
//uniquie fetching strategy objects for IParent and IChild as well

IHuman human = Repository<IHuman>.Get(id);
this will return an implementation of the Person object, but I don't care because this bit of code does not require it.

Your code above looks like instantiating the customer will load it from the database. I would advise against this. Your entity now has 2 responsibilities:
1. control customer behavior
2. access the database
using either the DAO or Repository patterns can seperate these concerns.

Jason Meckley
Specialty Bakers, Inc.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close