<-- 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!"
>

That's all I'm saying. The DAL should handle these things, not the BO. That's why I'm against using table names or SQL statements in the BO like you did in the framework. Besides, 1-to-1 raltionships do exist. I'm not saying that every single logical entity should be mapped to a physical one, but the developer may (and has the right to) use them whenever he decides to. The DAL (which in the case of frameworks, is a high level utility) should be able to handle such cases by relieving the developer from writing the appropriate code, and these tools in fact do exist.


Regards