OOP and Web application

[logidude]

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.

Suggestions/Ideas??

 

[jmeckley]

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
Programmer
Specialty Bakers, Inc.