Question

I’ve been having trouble finding the right design pattern for the following situation:

I’m programming MVC with PHP-Activerecord and a custom framework in an enterprise setting with a SOAP-based SOA. Now I’m trying to access and/or persist basically the same entity over different access layers, depending on the situation. To be a bit more to the point, I will choose an example:

There is a “Member” entity in our system. Now one way to access this member is over a SOAP webservice for which I have written an abstractor:

class Member extends ServiceAbstractor {}

Pro: Live access to the data (there is no other way for me to reach the production database directly).

Con: Pretty slow and I can’t do things like a “JOIN” with other entities or a “SELECT LIKE ‘%member1%'” easily due to the architecture which I cannot change.

Another way is to access the same entity through an older database replication. For that I would use a syntax like this:

class Member extends ActiveRecord\Model { /* Connection 1 */ }

Pro: Blazingly fast and I can do all the fancy stuff described above to do filtering, reporting and aggregation on the Member Data with SQL.

Con: Readonly, data is a little older (but does not really matter for most applications).

Sometimes, I even need to store additional metadata on the member, like who changed something about it for example.

For that I would use a local MySQL database, also with ActiveRecord, but on a different connection:

class Member extends ActiveRecord\Model { /* Connection 2 */ }

Now I would basically love to work with the same entity “Member” in a logical perspective, but obviously I cannot inherit the same class from three different access layers.

Probable use case: Get a member ID via a partial name search from the database copy (SELECT LIKE), then get the “real” member from the webservice, update it with something and then store the editor and last changes for this member in my local database.

Now I could name the respective classes something like “Member”, “MemberCopy” and “MemberMeta” (?), but that leaves me a little unsatisfied, as think I’m talking about the very same entity here.

Does anyone have similar problems and/or some advice on naming or design patterns for this issue?

Answer 1

How about using a logical plain and simple class Member (so not as an entity object) and three different DAO classes (one for WS, one for you replicated DB and the remaining for your local DB) that all take as input and return logical Member objects?