Fog Creek Software
Discussion Board




So...Joel's Still Using DAO.  Is Anyone Else?

Reading Joel's latest post on the front page, I'm pleasantly surprised to find that CityDesk uses DAO.  It's a nice example of "if it ain't broke, don't fix it" - DAO remains perfectly adequate for use in desktop applications, despite the push to move to ADO for everything.

Now I'm curious - is anyone else releasing apps into the wild that use DAO?  And is DAO even going to be supportable in future versions of Windows?

Norrick
Friday, January 03, 2003

P.S.  Thanks for the documentation, Joel...I can use that idea on a project I have coming up.  Which makes me wonder...I don't suppose you'd be willing to save me a lot of time and share the source code to your entity classes, wouldja?  ;)  Heh.

Norrick
Friday, January 03, 2003

Does anyone use or can recommend a good data layer generator?  I.e. something that will take as input a database of tables and generate a default general data access layer code for you that can be customized later on through overrides, etc.?

HeyMacarana
Friday, January 03, 2003

If youre using access why not?

Daniel Shchyokin
Friday, January 03, 2003

This is the first time I've heard the term "Entity Class" used to describe the process of creating a class for each table/entity in the database.  I always thought it was common practice.  I've been using this technique since I was in school. heh.  And yes, (before I lost my job) I used DAO and ADO every day.

Anonymous
Friday, January 03, 2003

I made up the term "entity," it is fairly common practice but I don't know what other people call it :)

When you're coding in MFC with DAO there's some kind of class wizard that sort-of autogenerates these things for you, but the autogenerated stuff is never as good as what you would create using just-in-time class design. (When we create entity classes we start with virtually nothing, and only add methods as we discover a need for them. Sometimes you don't have any List method, sometimes you have 12 varieties (e.g. ListNonDeleted, ListInFolder, ListByDate, etc.)

Since our code all maps directly to our tables, there's not much point in sharing them, but it might be a neat idea to ship the entity classes, as source code, to people who want to write add-ins or extensions to CityDesk.

Joel Spolsky
Friday, January 03, 2003

If you want to target Windows95 clients then ADO is not feasible.  You absolutely won't want user to download huge ADO runtime.

Amour Tan
Friday, January 03, 2003

In response to the question about a data layer generator:

This book has a concept of "Data Objects" (in VB) that are closely tied to database tables:
http://www.amazon.com/exec/obidos/tg/detail/-/1861002580
Enterprise Application Architecture with VB, ASP and MTS
by Joseph Moniz, Wrox Press Inc; ISBN: 1861002580; 1st edition (May 1999)

I read it a few years ago, and I don't totally agree with the approach described in the book, but the data object portion may be relevant for this topic.

The book author also wrote a VB application - "Object Factory" - that is intended to generate all the VB data access code as well as the database tables by asking you to enter essentially names and datatypes for all the properties of the object (which then also become columns in the corresponding database table)

The "Object Factory" code (and other sample code) is available for download at:
http://www.wrox.com/dynamic/books/download.aspx?isbn=1861002580
The download requires registration.

Philip Dickerson
Friday, January 03, 2003

It's not quite an "entity generator" but if you're working with .NET then you might want to check out Deklarit at http://www.deklarit.com. It takes as input a description of your "entities" and generates not only C# code, but a normalized database schema as well. I found it to be a great help for the relationally challenged (myself included).

-Chris

P.S. I did get paid to write a white paper for Deklarit, but I still think it's a cool product.

Chris Tavares
Saturday, January 04, 2003

Joel > I made up the term "entity," it is fairly common practice but I don't know what other people call it

You just happened to make up the same term that just about everyone else calls it. In relational db theory, entities are usually implemented as tables, so referring to your table wrapper as an entity is pretty common.

Troy King
Saturday, January 04, 2003

For a good generator, supporting both .NET and VS6, have a look at www.pragmatier.com

You can download a version using MS Access for free.

It generates all you need based on  class descriptions and you can also retrofit exisiting tables in it.

Philippe Back
Saturday, January 04, 2003

For a good discussion of the concepts behind mapping to relational databases, check out the sample chapter from Martin Fowler's new book, Patterns of Enterprise Application Architecture.  The chapter is titled "Mapping to Relational Databases".  http://www.aw.com/samplechapter/0321127420.pdf

If you like this stuff, you can still get old versions of the rest of the book's content at http://web.archive.org/web/20011110053223/http://www.martinfowler.com/isa/

Another good read for those who use .NET is the Microsoft whitepaper "Designing Data Tier components and Passing Data Through Tiers" at http://msdn.microsoft.com/architecture/default.aspx?pull=/library/en-us/dnbda/html/BOAGag.asp  It covers the pros and cons of 5 different approaches to implementing business entities.

ODN
Saturday, January 04, 2003

Back to the original question - yes, I still use DAO when working with Access.  From what I've read, it benchmarks faster than ADO when used with Access, and it has a much richer feature set.  More importantly, though, sticking with DAO for VB <--> Access work makes the code more consistent through time.

Nick Hebb
Saturday, January 04, 2003

Well, if you are using JET you do have DAO installed.

DAO is included, and is part of JET.

You can use ADO, but if you are talking about a standalone application, then ADO just sites on top of JET/DAO anyway.

In other words, you really can not avoid DAO when using  access/mdb file format. (ie: you might not use it…but is going to be on your computer!!).

In addition ADO does NOT have a data engine,but can only REQUEST data from some data engine.

Hence, if you are writing a standalone, or one that will not involve a server, then it makes no sense to use ADO.

However, ADO is one of those leaky abstractions that Joel often talks about. This means that all your code will still work if you dump JET and change the data engine to SQL-server. So, for sure there are advantages to use ADO. ADO  is simply is another layer of abstraction that is put on top of your database engine. (be it JET, or SQL server). Using it allows you to “dump” or change the data engine. (so, I can dump Microsoft’s engine and use MySql….see..it may not be such a brilliant idea to have told all us developers to dump DAO/JET!!!). Microsoft should be happy that many of use still use DAO. Since, if I had adopted ADO…then I can change data engine makers a lot easier!

(Hence, too much abstraction can allow your customers to change!!)

If your application is un-lkey to need a server, then I would not use ADO unless that is all you know.

Also, DAO has more functionality, and exposes a lot more of the JET object model. Of couse..it also performs better (but not too big of a deal these days).

We have been told since  what? 1998?,  that JET is gone, and not to be used? Well, I hate to say it..but it is still alive and well.

So, yes..I do recommend that one learn and use ADO..but there is NOTHING wrong with writing and using DAO.

In fact, for a JET standalone app..it is still a better choice, and I still use DAO.

Also, we don't know that Joel is using DAO in his code, he could be using ADO? (or is there some ref I don't know about?).


Albert D. Kallal
Edmonton, Alberta Canada
Kallal@msn.com

Albert D. Kallal
Saturday, January 04, 2003

>>
Also, we don't know that Joel is using DAO in his code, he could be using ADO? (or is there some ref I don't know about?).



Oh..ok just look at the front page now!!! duh!!!

Albert D. Kallal
Saturday, January 04, 2003

Seems to me that Code Generation in  Visual C++ could be based on DAO or on straight ODBC.  If you are already performing all data access inside C++ Code, why would you go to DAO and not ODBC?  The Class (Do they call it result set?) that wrapps it already provides most of what you would get from wrapping the entities, plus there is a method (no code generator in VC6 which was the last I used) to modify the result set to do bulk loading, which was much more effecient.

I can't beleive how much I just pulled out of long term memory.

Adam Young
Saturday, January 04, 2003

Thanks for the entity generator links guys!  Very interesting stuff.  I'll have to download and try out the programs plus check out the articles.

HeyMacarana
Sunday, January 05, 2003

Joel, you made up the term "entity"?  Are you sure you didn't steal it from J2EE?

Jonah Burke
Sunday, January 05, 2003

i borrowed it from ERWIN and the whole notion of entity-relation diagrams, in which the term "entity" refers to a logical thing corresponding to something in the real world, often corresponding to a table but not always.

Joel Spolsky
Sunday, January 05, 2003


A large Java software project I worked on a year ago had an 'Entity Layer'. 

Which was exactly a group of classes each relating to a database table and a few classes relating to multiple tables.

I have been assuming this term was indistry standard, obviously it's not as ubiquitous as I thought, given we are debating where it came from.

If proper relational database design instructs you to create tables based on the 'entities' you are storing data about, and modern OO programming design instructs you to create classes based on what 'entities' are present in the system, this type of entity layer is almost a fate acomplee.

The project by the way, crashed and burned, partially due to badly desinged entity classes that made it difficult to actually encode the required business logic and certainly broke Joel's rule about not compromising database efficiency.

Issues with Entities that have created Problems :

- will entities need to be nested ?  if so what goes inside
  what ?

- do you want array of entity objects being passed around
  the place or do you want 'super entities' that hold all the
  related entities.

- if you need information on entity X simply to instantiate
  entity Y do you go through the entity to get at it or make
  entity Y able to instatiate itself based on this entity x data.

- how much of an entity should be loaded from the database at different times ? 

- how to manage multiple entities all instantiated all in different stages of development at the same point of progress through the business process.  Were you to
commit multiple entities to the database would result in
inconsistencies between them.  Yet an entity is waiting
for something before it can proceed.

These are badly written up points, too vague to really
be analysed.

I will think about it all some more and post again.  I really need to figure out why our entity classes were so bad.

I guess this is the heart of computer programming, abstracting and breaking hard problems in smaller blocks,
I suppose one major problem was simply the lack of experience of the programmers.


Braid_ged.

Braid_Ged
Sunday, January 05, 2003

Braid_ged:

You may be interested in Martin Fowler's latest book, Patterns of Enterprise Application Architecture.

http://www.martinfowler.com/

I had an opportunity to study the patterns when he had it posted on his site as a work in progress.  If you are interested in a robust series of patterns for 'entity classes', this is the book for you.

To boot, all the examples are in Java ...

C. R. Millen
Monday, January 06, 2003

If I remember correctly from my little UML experience/courses then there are 3 types of classes in OO:

Entity classes - these represent the 'business' objects that you're application is managing

Control classes - these are classes that don't represent business objects (there is no 'state' associated with them) but they are classes that 'do' things. Consequently you don't actually create instances of them. In VB.NET you call their methods 'shared' methods. Can't remember what you'd call them in c++/Java/OO

Boundary classes - these represent the applications interface with the real world (hence the term boundary) and mean, for example, the screen, the keyboard, the mouse, the printer, the magnetic strip reader etc.

I'm currently doing a big OO based development (all aspects of design and programming) and I've found that I've had to work out a lot of things from first principles because despite the apparent adoption and abundance of OO technologies I've found virtually noone that can actually talk sensibly in detail about it (and explain what they're talking about)!

All my business objects are represented by 'Entity classes' but the actual work to make these persistent (i.e. load/save from/to a database) is all done in a 'Control class'.

For a start your 'Entity class' almost certanly won't neatly map to relational tables; at its simplest it'll usually be based on some kind of Join or possibly several database calls (maybe where the class has a collection of other classes within it).

Secondly, the persistence mechanism really has nothing to do with the business object. I should be able to change whether I store it to database X, or Y or a flat file or a post-relational database without having to modify the business object itself.

Thirdly, you can end up with database access code (e.g. SQL) spread around a lot of places.

ps. I'm not claiming to be an authority but having been through the pain of finding the best architecture for a very complicated product this wins for me.

Gwyn Carwardine
Monday, January 06, 2003

*  Recent Topics

*  Fog Creek Home