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.
@thgs it is a side project that will be maintained by me for the foreseeable future. It has some commercial potential I hope, but if it starts growing fruits then I will make sure to bring someone in who will have enough experience and no fear to dive in, regardless of the libraries used. The goal is to start minimal.
Looks like some dbal + data mapper is the way to go, the latter probably something custom.
@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..
@oliver I'm with @Crell , I'd write my own. I don't like how opinionated Doctrine is and how it keeps projects beholden to yester-decade standards, nor the magic for loading foreign key objects from within another object. A few common helpers for things like findById. Some value objects for UUID primary keys, JSON, DateTimeImmutable, etc.
I'd effectively reinvent what I did at my last greenfield job.
Yeah, it won't come pre-built with a migration generator but that's a secondary concern.
@zimzat yeah, on the surface level things seem to be attractive, but as you go further and deeper, facepalms emerge. Some dbal & a custom data mapper will probably be the start.
I use Doctrine on my day-to-day work, and have used Eloquent before. Eloquent I liked up to some point, but can't say that for Doctrine. I wish I had more time to build something like Eloquent but with less magic and bloat (simple to use but not trying to do everything imaginable)
@oliver Absent Doctine, I'd build the the thinnest layer on top of Postgres I can that gives me typed values. No mapping logic, no ORM hooks, just easily packaged and mockable SQL.
Add comment