Re: Business Entity Hierarchy OO question

Tech-Archive recommends: Speed Up your PC by fixing your registry

yeah dude.. let's just sit around and analyze for an hour.. whether to
keep a table in memory or in a database

times a hundred thousand

times a hundred thousand

times a hundred thousand

AS IF. KEEP DATA IN A DATABASE. IF YOU NEED TO MAKE IT FASTER TAKE A
FUCKING SQL CLASS INSTEAD OF HOPPING ON THE 'NEW PROGRAMMING LANGUAGE
BANDWAGON'

YOU TRENDY FUCKING DIPSHITS

-Todos




On Mar 13, 11:59 pm, "Bruce Wood" <brucew...@xxxxxxxxxx> wrote:
On Mar 12, 7:03 pm, "PS" <ecneserpeg...@xxxxxxxxxxx> wrote:





"Narshe" <nar...@xxxxxxxxx> wrote in message

news:1173724196.522005.187580@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I've been struggling with this for a while.

I have a business entity Employee that has a Company entity attached
to it.

Ex:

public class Compay{ // blah }

public class Employee
{
private Company _company;

public Company Company{ // get/set }
}

I'm looking for a good way to get the data for the Company reference.
Right now, the company info is got when needed, so there is a separate
query for the company. This presents a problem when you have a list
of Employees. You get 10 employees with one query, but then there are
10 more queries, one for each Company. This adds up if you have more
references on the Employee object than just Company, and if Company
has reference objects on it.

You can use lazy loading with a registry. With lazy loading until you
actually use the child object the Employee object is not going to do
anything. When you do request the Company you ask the registry. If the
registry already has loaded the Company then it returns the reference, if it
has not then it builds it and then returns the reference.

A little bit of code to give you the idea

class Employee
{
public Company Company {
get {
return Registry.CompanyByID(companyID)

class Registry {
public static CompanyByID(string companyID) {
if(companyList.ContainsKey(companyID))
return comapnyList[companyID]
else {
Company company = Builder.BuildCompany(companyID);
companyList.Add(companyID, company);
return company;

I know one way to solve this is to use a builder. So, you get your
list of Employees, pass it to a builder, the builder does a query to
get the Companies for those Employees, and you loop through and match
them up. I've found this to not work too well, which could be the way
I implemented it.

A easier way would be to build the complete company list at one time then
use this as a lookup "table" by key from the employee objects. If you have
objects that are fairly static then it can be easier to build them all when
the software starts and then delgate your properties to then like
public Company Company {
get{
return CompanyList[this.companyKey];

When LINQ in .NET 3.5 is released, this should solve the issue, but
that's not for a while yet and I still would like to know of a good
way to do it that will work for all languages, not just .NET 3.5.

There are other ORM products already available.

LINQ probably won't make a difference in this case: it'll just allow
you to express the same thing you're expressing now in a more compact,
elegant syntax.

I agree with PS, except that I wouldn't call it a "Registry". It's
called cache.

Basically, you load an object into memory only when some code asks for
it. Unfortunately, as is usual in computing, there are competing
considerations:

1) You don't want to load large tables into memory at start up just in
case you'll need them.
2) You don't want to make thousands of calls to the database to
retrieve single rows when you can make fewer calls to return groups of
rows.
3) The more you cache, the less you have to go to the database (over
time).
4) The more you cache, the more stale your data becomes, and the more
likely that the database will change "beneath" your cache, making
updates / writes that your user does conflict with the data in the
database.

For some tables it will be a no-brainer. If they're small and rarely
change, just load them at start-up, cache them, and grab objects as
they're needed.

For other tables it will be problematic: large tables that shouldn't
be read all at once, or tables that change frequently and so shouldn't
be cached for long periods.

Unfortunately there's no one-size-fits-all answer here. One of my apps
loads most of the tables upon first reference (because they're small,
< 1000 rows, and rarely change), but loads others piecemeal because
loading them at startup would cause an unacceptable delay.

Oh... and ignore the troll. Every newsgroup has to have a pet, I
suppose. It's just unfortunate that ours pees on the carpet.- Hide quoted text -

- Show quoted text -


.

Quantcast