Hey everyone, my problem is a bit complicated so i'll just split it in
sections so you can go straight to the point.
*Context : *
I work on a web application with a great amount of "historic" code and no
existing infrastructure. Most pages are hardcoded et go directly hit on the
database. This results in a lot of code duplication, no possibility of code
reusability, and greatly complexify the maintenance. I decieded to build an
infrastructure to use for the coming developpements, and doctrine seemed to
be a solid base for this.
However, the new infrastructure and the old code must coexist on the same
application, as I need to develop new features while maintening the old
ones, and I don't have the possibility to rebuild everything from scratch.
In order to keep everything working nicely together I have an apparently
simple requirement : *I have to use the same database.* Since the database
organisation is not adapted to an object architecture, I need to have
domain entities that aren't bound to tables.
For exemple, I have a person used for two roles, so an object oriented
management would be to make an inheritance from Person implementing
interfaces for these roles, but in the existing database there is an entry
for this person in each role's table, and a serialised array in the
parameters table used to associate them. Another exemple is a self
referencing database for composite pattern with an inheritance system for
different levels of entities.
*First try : *
Since doctrine simplifies dealing with the database anyway, it looks like
the best thing to do is to build a wrapper around doctrine, exposing
business entities that are adapted to an oriented object design while
manipulating doctrine entities, bound to the database. My idea is to use
decorators embedding one or more types of doctrine entities, to have the
possibility to manipulate one table with several entities and several
tables through a single entity when I need to.
To benefit from doctrine's repositories, events, cache, lazyload, etc, my
first guess was to make themselves entities, and to use an override of the
entity manager delegating persistence to the embedded entities when
manipulating decorators.
Ex :
public function persist($entity) //override of entity manager's persist method
{
if ($entity instanceof PersistenceDelegator)
$entity->persistEmbedded($this); // simply calls persist for the
embedded entities
else
parent::persist($entity);
}
This along with custom repositories delegating requests to embedded
entities repositories and building the decorators from them, etc.
Obviously it brings a lot of problems, and needs a lot of dirty fix to stay
compatible with events, lazyload, etc.
*Might be better ?*
Eventually it made me realise that doctrine is really not adapted for what
i'm trying to do, but hopefully offers good entry points to build an upper
layer on it.
My idea so far is to make an implementation of doctrine's interfaces to
manage my decorators, delegating persistency operations on the embedded
entities to doctrine. I came up with this simple design :
The problem with this is that I have to reimplement doctrine
functionnalities on my decorators, such as cache management, lazyload for
associations, events, etc.
Is there any better way of integrating it ? Or a simple system to link my
decorators to events, and lazyload, etc ?
*tl;dr : I want to make a layer on top of doctrine to manage non-database
related entities. Is my solution broken ?*
Thank you for your help !
--
You received this message because you are subscribed to the Google Groups
"doctrine-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/doctrine-user.
For more options, visit https://groups.google.com/d/optout.
