Initializing object properties based on a foreign key

[JudyBarer]

I have a class that has a foreign key as one of the properties of the class. When I create a new object of the class I want to initialize the key to a particular value. Obviously I do not want to hard code the value based on a particular record in the database. Should I create a table in the database of constants such as this foreign key and then have the Business Layer call the dal to get the key? I am trying to create an N-Tier application with a business class and a Dal.
Thanks for your help
Judy

 

[jmeckley]

ids, foreign keys, etc. are database concepts and don't truely belong in the domain. however an id relating to primary keys is needed so that your dal/orm of choice can access the data.

that said, your domain objects shouldn't have FK ids fields. at most they should have an Id field which correlates to the PK in the database.

for example the database may have a table named order which has a FK to customer on customer id. the domain model would contain 2 classes. Customer and Order. Order would have a field named Id and Customer would have a field named Id. Customer would have a collection of Orders and Order would have a field named Customer. but Order would not have a field named CustomerId.

data access is a solved problem and most (if not all) OOP languages have a solution already
.net > Nhiberante or Active Record
java > Hibernate
php > Pear
ruby > Active Record
etc.

I wouldn't roll my own DAL, I would use an established library instead.

Jason Meckley
Programmer
Specialty Bakers, Inc.

 

[JudyBarer]

>>for example the database may have a table named order which has a FK to customer on customer id. the domain model would contain 2 classes. Customer and Order. Order would have a field named Id and Customer would have a field named Id. Customer would have a collection of Orders and Order would have a field named Customer. but Order would not have a field named CustomerId. <<
Let me explain the situation further. I have a table of companies that have associated kosher certifying agencies. So I have two tables in the database
1) Companies
2) Agencies
Each company can only have one associated agency so I can store the ID of the agency in the company table record. Even if you want to look at the agency as a collection with one record - I still need to initialize the collection to a specific Agency - which means I need the ID of the agency.

Thanks
Judy

 

[jmeckley]

so your entities would be set up this way. (as one example) Note that the customer has not knowledge of the agency id, only an agency.

class customer
{
   int id {get;set;}
   agency the_agency {get;set;}
}

class agency
{
   int id {get;set;}
   IList<customer> customers {get;set;}
}

the database will have an agency_id column in the customer table which maps to the pk of the agency table.

Jason Meckley
Programmer
Specialty Bakers, Inc.

 

[JudyBarer]

It could be set up that way.
class agency
{
int id {get;set;}

IList<customer> customers {get;set;}
}
The agency also has many other properties such as name,address, contacts. It also could would have other collections under it.

>> Note that the customer has not knowledge of the agency id, only an agency. << - What if the user changes the agency associated with the customer - how would the correct ID be maintained?
IList<customer> customers {get;set;} Would this list get updated to maintain it? That would mean the user selects the new agency and that ID gets written tot the database record and then the list of customers in ID is refreshed?

I'm not sure if what I am saying makes sense. I hope you understand what I am trying to ask.
Thanks
Judy

 

[jmeckley]

yes, it makes sense. your at a crossroads where domain behavior mets database data (tables) it's a difficult concept to grasp, but once you do, a light bulb will go off.

yes agency will have it's own properties. and it may even have it's own collections. this is all part of the "aggregate root" (this customer in this example).

in the domain a customer can change agencies simply by changing the agency

customer c = repository.get(id);
c.agency = new agency();
repository.save(c);

think of an agency as an agency, not an agency_id. the id is simply there to retrieve the agency from persistence storage. once it's retrieved the id shouldn't have any meaning in the domain.

for more clarification on this subject read the online docs for hibernate or nhibernate. they can explain this much better.

basically the domain deals with objects and the database deals with PK/FK/attributes. it's the responsiblity of the ORM to map the 2. but once mapped the database shouldn't have any effect on the domain.

another way to think of it... the database only exists because we are limited by memory, IO and up time. if these where unlimited we wouldn't need a database at all.

Jason Meckley
Programmer
Specialty Bakers, Inc.