Should Class Design = Database Tables? 3

[stnkyminky]

I've normalized the database as far as I feel comfortable doing. This application is tracking sales leads.

I've got a table called Leads which stores information about the lead themself.

Then I've got a table called Company. This is where I store the lead's company information.

I've already got a lead object created. My question is this, Should I create a company object, which could be used in other parts of the app, or just store the company info in my lead object? I do have a CRUD screen for the companies.

If my assumption is correct and I do need a company object....how often, within reason, should my classes reflect my database?

Scott
Programmer Analyst
<{{><

 

[vinidel]

Hi stnkyminky,

Your question (how often, within reason, should my classes reflect my database? ) cannot be answered straight forward.
I believe its a conceptual question.
I won't beat around the bush, so let me try to share some info that I have with you.

In OOP there are three types of objects:
1. Entity Objects (that talks to database)
2. Interface Objects (GUI forms)
3. Control Objects (Transactional or functional)

Four Type of Classes:
1. Entity Classes (mostly data containers)
2. Interface Classes (Your Form class)
3. Control Classes (You create for functional use)
4. Abstract Classes

My experience is that with GUI applications, you will create above three objects & first three classes, knowingly or unknowingly.

But if you spend good amount of time on your requirements model analysis, and have context diagram and ERD diagram to their atomicity, then probably you may be able to answere your own question.

I just wanted to share info with you, it might help you.

 

[jfrost10]

Your classes should reflect your database as long as its within reason.

HA, what a great answer eh?!


Seriously though, there is absolutely nothing wrong with a 1-1 relationship between your classes and your tables. In that situation, i think it makes total sense to create a seperate company object, which can then be used either side by side with other objects or as PART of another object (maybe your Lead has a company object as part of itself, or maybe you create a company object that has a Leads collection within it)

The possibilities become endless.

One main thing you want to achieve within your objects is the idea of high cohesion and loosely coupled.

They need to be able to snap together really easily (high cohesion), but not be so dependent on each other that they become too brittle (loosely coupled).

So it makes sense to create a seperate object for some of your database items, and have other classes that can use them, or use them on their own.

D'Arcy

 

[chiph]

stnkyminky -

Will you be displaying lists of Companies or other objects to the user? Or be working with them internally?

If so, you'll want to use a design pattern called a DTO (Data Transfer Object). What it is is just the data that represents your company. You won't have any database access routines in it, but you'll probably have a "validate" method and a "serialize" getter/setter. This becomes a storage location for a company, and very little else.

The O-O purists dislike it, but it is vital to solving one real-world problem: how to retrieve a list of objects from the database.

Most O-O books tell you to put the code to load the object inside the object itself. Give it a company ID, and it goes out to the database and gets info about that company. That's great, but what happens when you want to get info about 2 companies? You create two instances of a company object, each of which would go fetch itself. What about 100 companies? Uh-Oh, you just ran out of database connections.

So, what you do is put the code to fetch a Company, and the code to fetch a collection of Company objects in their own class. It's not really a factory (that implies something else), but it does return you Company objects.

Additional parameters to the GetMultiple method can help you with record paging. Often, you're looking at more companies than can fit on one screen, so you need to page to the next bunch. The GetMultiple method can take a "start" and "count" parameters so you can call it when navigating through multiple pages of data.

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first

 

[jfrost10]

As a self described OO purist, I actually agree with Chip on this...and have my own spin on it: you can have the best of both worlds.

Chip's suggestion is one that I use in my applications, although my objects within the collection aren't just placeholders; they're full fledged objects. He's right that to fill all of them wih seperate database hits would be illogical. Returning a data table with the informtion, and having the collection object fill the objects from it makes more sense.

But each object should still be responsible for itself. By that I mean that each object should know when its had its data changed (update), when its been flagged for deletion (deleted), and when its new (added). So I don't think that the objects should just be placeholders for the fields. Getting the data via data table is one thing; updating/adding/deleting the objects is a whole other ball game though, and one better suited by each object taking care of itself.

D'Arcy

 

[chiph]

I wasn't going to mention the "dirty flag", and so forth. That's implementation-specific stuff. But you're right. The DTO would have to have additional member fields in it to hold things like that.

One of the things I've seen done is to have "before" and "after" copies of the data in there. This gives you a little bit of an undo capability, as well as helping out with concurency checking when you go to update a row in the database.

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first

 

[stnkyminky]

Well I've got a company object that can stand alone and will be used during the mod screen for companies.
Ex. Company.Address1


I've also got a property in the lead object that holds information about their company. So in essence I'm using the company object mentioned above. Ex. Lead.Company.Address1

Furthermore, I record and display Trade Show and Ad information. I had created objects for these tables as well. I then added property for these objects in the lead object because I'm tracking how the lead found out about us.
Ex. Lead.TradeShow.EventID, Lead.Publication.Name

If interested I'll post the class diagrams soon.

Thank all you for your help and insight!

Ex. TradeShow.Name


Scott
Programmer Analyst
<{{><