Android Couchbase lite architecture?

Question

We are building a project using couchbase. On Android, I use couchbase lite. I usually work with relational databases, and because I'm new to couchbase, I have trouble finding the “right” architecture. I understand the basic concepts, which I think, but all the samples and manuals seem to adhere to some simple setup when they access the database directly in the "Actions" section.

I'm more used to the fact that there is some kind of database abstraction where the business logic only sees that the POJO DTO is delivered via the database interface or some kind of DAO or something like that. Thus, I now annotated my model classes and started writing a simple OR block, but with different data types, foreign keys, etc. It takes quite a lot of time.

Do I really not notice the point here? I can’t imagine everyone doing this? Am I all writing methods that convert documents to POJO model classes for each class separately? Or use a json parser for this (but this will not work for foreign keys unless I load them too)?

Sorry for the load of questions, but I feel like I'm missing something obvious here. Thanks!

Answer 1

Let's try to answer your questions:

Do I really not notice the point here?

No. You can think of noSQL CB as a persistent cache of distributed objects. So this is not RDBMS. However, the DAO pattern fits perfectly into this model ... since you are dealing with DTOs / ValueObjects / POJO at the DAO and noSQL level.

I can’t imagine everyone doing this?

I suggest writing one universal Couchbase manager class that can save / retrieve POJOs. Then you can reuse it in your DAOs.

Anyone who writes methods that convert documents into POJO model classes for each class separately? Or use a json parser for this (but this will not work for foreign keys unless I load them too)?

You may have one common code in your Couchbase manager class that does the conversion from / to json to POJO. Thus, you only work with POJO and don’t see json in your application code (outside the Couchbase manager class) Here is an example of such a class:

public class CouchbaseManager<K, V> { private final Class<V> valueTypeParameterClass; @Inject private CouchbaseClient cbClient; @Inject private Gson gson; public CouchbaseManager(final Class<V> valueClass) { this.valueTypeParameterClass = valueClass; } public V get(K key) { V res = null; String jsonValue = null; if (key != null) { jsonValue = (String) cbClient.get(key); if (jsonValue != null) { res = gson.fromJson(jsonValue, valueTypeParameterClass); } } return res; } public void put(K key, V value) { int ttl = 0; cbClient.set(key, ttl, gson.toJson(value, valueTypeParameterClass)); } } 

Then, in your DAO code, you create an instance of CouchbaseManager for each type:

 CouchbaseManager<String,Customer> cbmCustomer = new CouchbaseManager<String,Customer>(Customer.class); CouchbaseManager<String,Account> cbmAccount = new CouchbaseManager<String,Account>(Account.class); // and so on for other POJOs you have. // then get/put operations look simple Customer cust = cbmCustomer.get("cust-1234"); cust.setName("New Name"); // mutate value // store changes cbmCustomer.put(cust.getId(), cust); 

Now about the "foreign keys." Remember that this is not RDBMS, so there is a concept of a “foreign key” before your code. For example, the Customer class may have an account identifier:

 Customer cust = cbmCustomer.get("cust-1234"); String accId = cust.getAccountId(); //You can load account Account acc = cbmAccount.get(accId); 

So, as you see, you do everything yourself. I would like it to be a JPA or JDO implementation / provider for Couchbase (e.g. DataNucleus or Hibernate )

You really have to start with your POJO / Document project to try to split the POJO objects into “pieces” of data in order to get the right balance between coarse and fine-grained POJOs. Also see this discussion for key / document design considerations .