Uptate :
First i should clarify a point that was unclear on my previous post : I do
not override the EntityManager but use a child class of
EntityManagerDecorator (i started with ObjectManager, but I need to expose
more functionnalities to my buziness code.)
That might be a terrible idea, but I thought I could use a custom child
class of UnitOfWork on my EntityManagerDecorator, and make it persist my
entities decorator while preventing to actually insert them in the database
with a false persister. This way i could still have them referenced.
As I redirect accessors for fake properties directly on the embedded entity
throught a declaration of the corresponding properties, I can use the same
declaration for dynamically converting filters using the decorators members
into filters that actually works with the database. As for the event, I can
make the reverse process : I redispatch events with a changeset recomputed
to be seen as modifications on the decorators.
This would obviously result in a loss of performance, though.
Le jeudi 17 décembre 2015 12:22:56 UTC+9, Josian Chevalier a écrit :
>
> 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.
