[Boost-users] Boost-enabled loosely coupled ORM serialization

Subject: [Boost-users] Boost-enabled loosely coupled ORM serialization
From: Michael Powell (mwpowellhtx_at_[hidden])
Date: 2013-04-05 05:19:27

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.

Regards,

Michael Powell