>Assuming that you still agree with me that the object model and the data model are both derivable from the conceptual model, coding the DAL by hand makes little sense since the DAL would be derivable as well. Data driven mapping adds a dynamic layer on top of static structures, which seems wrong from the start. Plus it adds the burden of maintaining the mapping data as the conceptual model and it's derivatives change.
>

But there is another aspect of a DAL: as a layer of abstraction between the middle tier objects and the persistence mechanism. Ideally, the DAL should shield the application programmer from the details of how and where data is persisted. Obviously, writing sql statements against physical tables doesn't do that. I guess generating a DAL in source code could but I think that is an inflexible approach. That would be generating something that is static over something that could be dynamic, ie. the database tables.

Thats why I think a persistence layer is the way to go for large projects. I just want to say to my DAL, "Here is my order business object. Save it. You know how it is saved. It could be saved in one table or two. It could be saved in SQL or Oracle. It could be persisted in a database or as XML. I don't know and I don't care. Just save it!"


>BTW, any attempt to derive the object model from the data model is doomed because a data model view of a conceptual model is analogous to a 2D view of 3D object. Some distortion is always introduced producing the 2D view and in the 2D view you never see the entire 3D object.
>

Your exact sentiments are echoed here: http://www.agiledata.org/essays/drivingForces.html