Decoupling data layer - how to deal with one to many relationships?

Using Swift
1

Hello there,

I've watched a few videos on "best practice" decoupling your database / data layers via another layer.

From research, usually these are encapsulated in plain structs and a "translation" layer which bridges the entities (ie: core data) and the types you've created, and converts to core data and back from core data.

An example of this can be found on:

All the examples I've seen assume your data layers are 1 offs, that is; they don't have relationships with anything, and I am stuck on how to deal with one to many, or even many to many relationships in such layer management.

For example, lets assume you have a factory that has production; players can own the production

So, a simplified structure might be:

class FactoryProduction {
   weak var factory: Factory?
   weak var owner: Player?
   var productionUnits: Int
}

Factory -< FactoryProduction - Owner

But here's where I get confused and stuck;

Should your objects even have relationships?

When "isolating" your data layer, do you need to manage the responsibility of managing relationships between objects or not?

Its okay if you have one-offs, like an array of Todos, but what I get stuck with is what to do when the items in my array also have relationships.

I appreciate any assistance on decoupling data layers.

With thanks

2

Well in the exemple you provided from Realm.io there are indeed relationships, though you may have not considered them as such: Event is related to Location and Person.

As a rule of thumb I would say that you should avoid having relationships (even 1-1) in your objects and build what is called an Aggregate Root to handle this. This allow to handle easily 0, 1 or n relationships.

So here your FactoryProduction seem like one (although why making relationships nil?) and Event from Realm.io should have neither location nor user.

If it might help a little bit, I wrote an article not long ago on the subject: modeling done right

3

Thanks for the assistance.

The rule of thumb stuff does help. I am finding it quite hard to create models that bridge two more more objects without using class references; so I'm hopeful that the post will assist me in resolving my confusion.

The factory production could be nil in that it is in a state where it doesn't exist. IE: A factory can exist without any production; or indeed, any player owning it

4

I guess it's because it's counterintuitive to what you've been doing up until now. I felt quite the same when moving to Swift and struct just to found out it was actually playing nicely and avoided me tons of bugs. And when needing reference I just wrapped my Aggregate Root into an Observable class.

Don't hesitate to google search Aggregate Root term, it's a common term in Domain Driven Design.

Hard to respond accurately without really knowing the case, but feel to me that if FactoryProduction has no production and no owner it should just be nil object (FactoryProduction?).
If you have indeed other properties than those two (and which don't rely on them), I would advise making a Production object and just aggregate factory, owner and production in FactoryProduction.

1 Like