Rapid Data Mapper

Anyone use this?

I’ve been looking at the documentation and seems like a well thought out, explained and powerful system. Some things that caught my eye was all the work that went into supporting relations, event and plug-in support. Not to mention how well documented it is from low to high level functionality.

Rapid Data Mapper:
http://www.rapiddatamapper.com

discuss

Well the nice thing about needing to go through the mapper is that all the mapping is contained within the mapper. By providing a way to get the tracks through the domain object mapping logic must be indirectly or directly injected into the domain layer in some fashion. Though, I believe the rapid data mapper does support lazy loading, but the focus seems to be very much the eager loading power of the system.

Copying the schema provides a lot of functional advantages such as the ability to use events to manipulate data or map it in different ways. I know what you mean, but still there are a lot of positives that come with having a concrete class definition for the mapper than it being dynamically generated and relations “guessed” using some form of naming or comments to resolve them properly.

I do agree with that, but I don’t see the problem with using the DB schema as a basis of the business object definition as long as it can be overridden where needed. However how often is it that a mapper will be referring to a single database table? Imho, a very high proportion of the time and in most cases (if your database is correctly designed) there will very often be a 1:1 field mapping between a class definition and a table definition.

Perhaps it’s just because I’m an advocate of convention over configuration, but I find replicating the database schema in php rather tedious and pointless.

Well by mapping directly from the database tables aren’t you essentially using a glorified ActiveRecord rather than a true mapper? A mapper is meant to translate information stored in the database to true domain representation of the business goals at hand. By using the exact db table schema your more or less using a ActiveRecord (table based) level of thinking than one that truly decouples the database representation and domain operations at hand. No?

True but I think that doing this gives far more benefits than drawbacks .

Copying the schema provides a lot of functional advantages such as the ability to use events to manipulate data or map it in different ways. I know what you mean, but still there are a lot of positives that come with having a concrete class definition for the mapper than it being dynamically generated and relations “guessed” using some form of naming or comments to resolve them properly.

Well I was more talking about the need for creating a class which had members for each potential field. In simple cases (which, in my experience, is anything up to 50% of the time) it makes more sense to describe the fields using metadata from the data source and let the data source handle data checking (e.g. trying to write to a field which doesn’t exist). It also allows for a much looser coupling between the data object and the data source. I could alter the user table (e.g. adding a field) and I only need to make the change once in the database… I don’t also need to inform the mapper and/or related entity class definition.

My own mapper can do this:


$user = $this->mapper->user->findById(123);
echo $user->username;
$user->firstName = 'Tom';
$this->mapper->user->save($user);

without any configuration of a User Mapper or User Object (by default it guesses that it should use a database data mapper and map to a table called user with id as the primary key). I can create a user object or a usermapper at any time and it will replace the functionality throughout the application. This allows for very fast development using an extreme programming approach.

Definitely well documented, which is an immediate plus.

I didn’t use it or look any further than the documentation, so I may have overlooked a few things.

Imho, it has the same problem as a lot of other mappers. Way too much initial set up. I don’t believe there is the need for copying the database schema into php, which is what’s needed here (and with most others).

The use of a singleton as an entry point is messy.

from this page: http://www.rapiddatamapper.com/version/0.6.1/chunked/ch01s05.html#id36896960

This is the killer for me: It doesn’t look like you can pass the “Artist” object around and access the tracks without going back through the mapper. This creates dependencies to the mapper where they should otherwise not be required. It also creates verbose code. Instead of just being able to call $artist->tracks from anywhere you need to go via, when you may want data from several objects down it shows that it’s an OO interface to a relational schema.

I believe Lachlan’s mapper from http://www.sitepoint.com/forums/showthread.php?t=687271 addresses the relations/mapper dependency issue better.