@icedquinn yea remapping has been in my mind. I do use the right control sometimes, also been thinking about home row mods but havent figured it all out.
I've seen those a little bit, learning the basics without them still.
If you were about to start a medium-sized #PHP project, what would you choose as an #ORM, and why? It should be something stable and well maintained. If the business takes off, then there should be no need to replace that layer.
Caveat: imagine that Doctrine and Eloquent haven't been invented yet.
Who is going to use with this code? I think the answer to that will be fundamental.
Say you already have a team that proficient in using Doctrine, it might be a good idea to just do that.
If you don't have a team like that and what you really want is something that would not be an impediment, scope out the real needs, right now. I assume from what you say need a mapper of some sort and DBAL ? You could roll your own with say valinor for mapping or similar + optionally a DBAL lib.
@oliver Nevertheless, if you structure it well AND that layer becomes a burden in the future for whatever reason, because it is structured well you will be able to replace it easily.
In reference to hexagonal / layered architectures.
@oliver I mean.. the way you put it, the data mapper is only convenience probably. I think valinor supports stuff like nested levels that ocramius/GeneratedHydrator doesn't for example. Not sure 100% for either.
Personally, I would not consider writing my own data mapper, just for the sake of not losing time with the project.
Recently, I favour the notion of "first version is probably throw-away code" and just try to make it work. It all depends on what level you design things, I guess..