Hello,
I am coming up on a decision in the architecture I am working on. I want to serialize some domain data to a data store. I'm aware boost has serialization features, which I'd like to explore further.
I'm coming at this first from a boost standpoint because I am successfully building upon it for other parts of the engine and domain model, so boost is available right now. I am expecting I might go with a third-party library like ODB, Wt::Dbo, or something like that.
Also, background, I am no stranger to ORM concepts. I was first exposed to them through Java, C# .NET, and have dealt with Hibernate, NHibernate, Fluent NHibernate, and so on. So vocabulary-wise, grammar-wise, we're talking the same language.
Also, I'll defer backend decisions until later. Probably that will be somewhat determined by target platform support and so on: landing on ArchLinux ARM.
For now, my focus for now is on keeping ORM intersection with my domain as loosely coupled as possible. For anyone versed in ORM nuances, for obvious reasons, I want for the ORM to be as transparent through the domain model as possible.
I want to steer clear of the active record anti-pattern whenever possible. I'd like to gear up for a repository pattern whenever feasible. No time to get into that discussion why I believe these are patterns or anti-patterns. That's a separate blog for another time.
Wrappers like smart pointers, smart collections, are understandable, and may be the way to go, but put opaqueness layers between end-users of the domain objects and the rest of the model. Will use them if I must, but I'd like to avoid them if possible.
Additionally, given some language "features", perhaps "limitations" if you will, of C++11, as contrasted with a C# let's say, I also want for any ORM code, whether meta-programmed or not, to be as non-intrusive to the domain model as possible. I've seen a ton of code that have persist methods, friend access, macros, and such.
Sounds like a tall order I know. Call me spoiled on the "niceness" of .NET, Reflection, and so on. More likely I'm getting reacquainted with the practicalities of using a paradigm-rich language like C++11. Now back to the "real world" what the rest of us deal with.
Realistically, a sober look at it, I believe there will be tradeoffs: SOLID is my goal, sufficiently extensible to meet the seams we'll need to meet, yet maintainable at the end of the day.