Model layer design guide

I’m developing a UWP using with V2.0 APIs. The MOST questionable part of development was that Model layer and interaction with my view model. I need some help and to design my Model layer. I looked for V1.4 APIs with those todo samples, and I really got nothing.
In my old fashion style with Entity Framework or something simpler like SQLitePCL, It’s not that complicated. At least there are some guidelines available. But in couchbase NoSQLish style, I’m really doomed.

The fist part is that in both SQLitePCL and EFCore we are saving objects. And those libraries convert it to/out of database records. Those objects have the same presentation logic that we wanna have it in the VM layer. Let’s say that we have an student having a name and ID. We make a class and save the object in those libraries. But in out NoSQLish way at first we should convert out presentation object to a dictionary, then save it. after querying and getting values, we should again convert those dictionaries back to object so we can have them in our presentation logic. (Convert a list of dictionaries to an observable collection of student object). I tried these conversions with deferent ways and I made some stuff for them using system.reflection but again it sucks ant it make ALOT of mess in my code. if you have any idea about it, tell me :slight_smile:
Secondly, there is problem with syncing the VM with Model layer, listening to database changes. note that the database changes can be caused by another device(Via sync gateway).

I’m really waiting for you guys to help me to make my Model layer.

There is no way around making it into a dictionary first, no matter what you do. The reason for that is because what you are really doing when you do that is converting your class into a JSON representable type. SQLitePCL, and I assume EFCore, both use schema to determine what information they need to save and retrieve but Couchbase Lite does not make use of that in the way that the others do. It is a schemaless model, and that makes it harder to save and retrieve objects directly because there is no guarantee that the layout of the objects is consistent.

That means that you first need to examine what you are actually getting back and determine how to use it. Right now everything may be the same, but can you say that for the future? The solution will probably either involve reflection or a method similar to Apple’s NSCoding in which you are presented with a key-value collection (or document) and you can serialize into or deserialize out of it.

I think your model layer should be doing this conversion and holding an observable collection or firing an event when it has new data and letting the view model convert it into the presentation class. Since it is your data, you know best how to convert it out of the state it is in. You don’t necessarily need to use reflection, you could just pick out the keys and values that you need.

For what it’s worth, we are planning a feature like this but it was moved out of 2.0 some time ago because of time constraints and currently is planned for 2.1. It will probably feature a method on a document to populate a class with its data. It’s doubtful that directly retrieving objects will ever work correctly because of the potential for layout change by the user. Saving objects directly might be something that can be worked in though.

Thank you Jim.
I’m about to make those conversion stuff. But I’m really caring about performance. These extra codes can effect.
But anyway, as it’s NoSQL, there are a lot of ways and while no same way or the recommended guide for M layer(at least for now).
I’m going to think more about it and continue coding this layer. I’ll share anything cool I founder here in this forum and pull request anything I founded cool in code.