Object/Relational Data Access Layers... 1

[steverbs]

Hi all.

A while ago, my company began implementing the Microsoft .NET framework for application development, and I have a background in Jade, which is a pretty idealistic OO development environment. Jade completely hides the DAL, meaning that all developers have to think about is whether an Object is persistent or not at instantiation time and I have been trying to carry across much of Jade theory to our .NET developments. However, while the O/R DALs I have developed work well enough, I am still concerned about their efficiency (application performance, data-access times, etc.) and am thus constantly changing their structures, which is starting to drive the rest of my development team around the bend.

My question is, is there anywhere, Internet, books or otherwise, that I can read up on Object Relational Mapping? I feel that I have come up with a satisfactory means of persisting individual Objects. My primary concern is what to do about Collection Objects to efficiently achieve one-to-many and many-to-many Object relationships.

Any help is greatly appreciated.

Regards.

Stephen.

 

[dragonwell]

Hi, Frans Bouma!

I have been studying the framework that LLBLGen Pro produces. I am trying to "follow it" all the way through, from the GUI on down to where the query takes place.

There is something that I don't quite understand (mainly due to my lack of experience/understanding). The EntityBase classes (f.e. CustomerEntityBase) use the DAOFactory to get a reference to the specific DAO classes needed to access data...

CustomerDAO dao = DAOFactory.CreateCustomerDAO();

Why don't the EntityBase classes just create the DAO instances using the

new

syntax? From what I can tell, that is basicaly all the DAOFactory is doing. Or is it?

I'm sure there is a very good reason and in fact a known design pattern, but I just don't understand what is being accomplished in having that additional step.

Regards,

David