Architecture/data layer

[matuella]

Adds the data layer core pieces, such as DatabaseRepository and its implementation with sembast.

Unit tests on most of cases are also done.

[ggirotto]

Although the DatabaseRepositoryImpl receives a database instance on its constructor, this data layer is not ready to handle multiple database instances. Have you though about this multiple databases necessity? How would you manage this in the current structure?

[ggirotto]

Maybe creating a single or multiple custom types to this return? This function signature is unreadable

[matuella]

There is no way to create custom types that aren't functions. This might be possible in 2.13, but not right now

[matuella]

@ggirotto

Although the DatabaseRepositoryImpl receives a database instance on its constructor, this data layer is not ready to handle multiple database instances. Have you though about this multiple databases necessity? How would you manage this in the current structure?

The idea is that we should not need to instantiate multiple databases just for the sake of performance. If there is a problem with performance, even if they are mitigated when split into multiple files, those problems will inevitably occur even if a single DB has too many elements. So if this is a problem, there are plausible workarounds, like parameterizing the constructor/openDB function. Although the underlying problem (which is the library not being performant with a heavy load of elements) is what should be solved instead, not creating multiple DB instances.

With this in mind, I have my doubts that it will be really necessary in the future, as we should eventually need to go to cloud to provide such amount of data, and not storing thousands of MBs for decks that the user will never use (possibly the majority) on the device.