Converting the map-like Document structure to a POJO with each key as a property, is going to be a fairly expensive thing to do and I can’t really see any benefit to doing it. If you really must have a POJO, I suggest a wrapper object that delegates property requests to the appropriate keyed query on the Document.
That said, you certainly can turn the document into JSON and then use one of the JSON packages to parse the JSON into a POJO. In addition to being wildly inefficient, that will, of course, hide one of the very best features of a NOSQL DB: that documents do not need to have identical properties.
I had similar issues with XML and C#, great at serializing and deserializing, however, expensive.
Would you advise creating a set of models, however the backing store within each model is mutable doc and the model exposing public getters & setters? (models will be nested)
I want to keep to the JSON native backing store, however also separation of data and models, allowing existing developers not having to deal directly with node management.