I'm currently devising my application's persistence framework...and I am debating two solutions for abstraction.
Option 1. The first, and simpler (but possibly more coupled to the database is a 2 layered approach. In this approach, data mappers pull data from the database and build business entities.
Rough diagram of workflow:
UserEntity <= UserMapper => Database
Option 2. The second, and more flexible (but possible overkill) approach is a 3 layered approach. In this approach, we have a THIRD object who's job it is to solely speak to the database, and return an array of data to the Data Mapper, who then creates an object.
Rough diagram:
UserEntity <= UserMapper <= UserDataRetriever => Database
Obviously the benefit of the first option is that it's simpler and therefore quicker to create. The benefit of the second option is that it's easier to change out my persistence methods, as I'd only have to change my DataRetriever's connection to the DB (and related queries).
As this site is going to grow in size very fast, I'd like to choose the most flexible option, without getting into anti-pattern land.
Which is better?
I would use the following:
Entity <=> Repository pattern <=> DataSource
The repository would do the mapping (or use an mapping layer internally).
The repository itself could use vanilla ADO.NET, and OR/M mapper, a webservice or anything else.