The Old Joel on Software Forum: Part 4 (of 5)

Initializing Entity Classes

I have a project that I am building using Entity Classes to access a Database, the way that Joel describes them in his article.

However, in the article Joel does not show how the Entity Class gets it's reference to the Database (which is essentially the root object). There are a few ways that I can think of to achieve this, anyone care to comment? Listed in order of best to worst IMHO, here they are:

1) Factory

Set oFolders = oRootObj.NewFolders()
oFolders.List
...
(Internally, NewFolders() creates the new EFolder object and hands it a reference to the DB before giving it to the caller.)

2) Initialize method.

Set oFolders = New EFolder
oFolders.Init oRootObj.DB
oFolders.List
...
(1 more line of code than #1, but similar)

3) Global Root

Set oFolders = New EFolder
oFolders.List
...
(Internal code of the class can access the DB when it needs it via the global variable)

Actually 3 is not an option because there will be multiple instances of the root (or document) object in certain situations.

Wayne
Saturday, May 8, 2004

Also, 2.5) Stateless?

Set oFolders = New EFolder
oFolders.List oRootObj.DB
...

Basically, pass the root/document object or the DB to methods of the Entity class that need it ("List" or similar type functions)

I generally create an Entity class object, use it, and destroy it all within one procedure, so techniques 1, 2, and 2.5 will all work for me.

However, I might change oRootObj.New[EntityName]() to something like oRootObj.NewEntity(eType as EntityTypeEnum).

Is this just a matter of style?

Wayne
Saturday, May 8, 2004

Just to quibble a bit....

I've seen that article, but I've never understood why Joel refers to the class that communicates with the database as an "entity" class. I've always seen it referred to as a data access layer class, or something similiar.

In fact, I've always seen an entity class referred to as the actual business object that is devoid of any database context. If you read any MS architecture books, this is the approach that they use. Perhaps other technologies differ in their naming convention.

Or perhaps I just misread his article.

Anyway, the way I normally handle it is that I first create an base data access layer class for the application. This class has a method that opens a connection to the database. Then, for each data access layer class that I need, I derive a new one from this base class and overload the method that connects to the database as needed.

I still use a factory approach in connecting to the database. Nothing is hardcoded to a specific database type.

Whatever
Saturday, May 8, 2004

"Actually 3 is not an option because there will be multiple instances of the root (or document) object in certain situations."

I use a hybrid model. Each Entity class has an optional constructor value where you can pass in an instance of the database connection. If that value is not provided, it goes to a global variable to get the connection. 90% of the time, only the main connection is needed so this works well.

All this work is encapusaled in the base class for all entities.

Almost Anonymous
Saturday, May 8, 2004

I believe that in Joel's implementation of the "Entity Classes", DAO is used as the database layer (or "root" object). I think adding anything else in between the entity objects and the database is just adding unnecessary complication.
Am I missing something?

Jordan Lev
Sunday, May 9, 2004

In my application, the mdb file represents a document, and I will need to have multiple documents open at certain points, but not very often.

Wayne
Sunday, May 9, 2004