Offline domain model best practice

0
An interesting question for the last day of the year. I've now build two big partly offline apps: For one, we went for completely seperated modules which were not even connected via associations to limit the retrieved data to a minimum. This of course also means seperate pages because of the seperate entities. This allows for selective synchronization (through access rules on the 'offline entities'), but increases development effort. For the other, we have a shared domain model and shared pages between the offline tablet and online desktop profilles. This however limits selective synchronization in the current set up of Mendix; access rules limits offline as well as online retrieval.   Based on other experiences, what is the best practice or are best practices for seperating domain model and/or pages for a partly offline app? It's quite a dilemma every time again...  
asked
1 answers
3

We've also built a partially offline application and we went with the seperated domain model approach (Although we connected the offline entities to the 'main' entities). Mostly because of the reasons you're also mentioning in your post. In my opinion: the quality and security advantages of this option greatly outweigh the increased development effort.

Another advantage you gain this way is that, in quite some offline usage cases, you may only want to have a subset of the data that the online application has to offer. With a seperate domain model you can enable this.

Besides this, some 'domain model features' (If I may call them that way) simply aren't available in offline apps. For instance: calculated attributes, autonumbers and default values. Inheritence is also a case to be carefull with when making offline apps. This could be another reason to use seperate domain models as you may want to use these ones in your online application.

answered