I have been developing android application for a while now. What we currently do is we first develop our UI components in the mean time web API developers will be completing the web APIs required, so when the web API is done we design our database according to the fields that we receive but It may lead to the problem such as we already have created created the models (DTOs) because we needed them for our UI components. So, it gets really hard to parse the received response from the web APIs and mapping those fields in our local database.

My question is what the best practice for doing these things?

  • Should we be creating the database schema first and then use same database schema for client and server and design our DTOs accordingly?
  • Are there any better way of doing these sort of things?

2 Answers 2


It also happens in web developments. So often. Webservice data model should not be conditioned by UI. It make it really unflexible and hard to scale.

In terms of web developemnt, in MVC pattern, C (Controller) is the facade in charge of transforming any business data model into a DTO. Such DTO's are neither designed for UI. They are a summary of the real data. Unbinded from database sessions.

However you are working at V (view) facade, so you probably will need your own data model. Oriented to the UI. It's somehow a wrapper or a composite model. This model should be the one you persist in your database. I would not store webservice datamodel because then you are strongly binding your App to that Webservice and its current version. In further versions of the API, model may change and you will need to refactor your APP model again. Too much overlapping.

In your case I rather prefer to implement Transformers that translate webservices responses into my UI Datamodel and persist this last (if needed).

If any entity of webservices datamodel is valid for UI with no translation, then I would persist it too. As it is. For example, master data.

Adapt the info to your own needs, don't tie yourself to a model that can change overtime and will force you to understand those changes in deep. A good plan of translation will prevent you from data model changes and it will make easier for you to deal with these changes. It also can prevent your App from crash because these data model changes.


Should we be creating the database schema first and then use same database schema for client and server and design our DTOs accordingly?

In my opinion, don't do that.

2 applications 2 data models 1-N translators


Final design would be something like this

Server-side: Back-end: ERM Persistente Layer: ORM Business layer: ORM entities

Webservices: - Controllers: consume ORM entities and transform these into DTO's. DTOs are like webservice data model.


  • Webservices client: consumes DTO
  • Driver layer: Transform DTO into App's data model.
  • App's business layer: App's data model
  • App's UI: consume App's data model through App's business layer.

If your app uses directly Webservices DTO you are bound to it for good or bad. If you design DTO thinking in client-side, will be hard to reuse it for another clients.

Like we say here: Let app to cooke the data and transform it into anything else. Leave alone server.

However if you are sure that wont be any other client consuming your webservices, then client app can just use DTO's.

Finally, dead-lines, budget and resources have the last word ;-). My propuse is the ideal scenario.

  • What I got from your answer was we should create separate UI datamodel and DTOs for our webservice right? Also could you please elaborate on why we should persist UI datamodel instead of webservice DTOs?
    – Sushant
    Commented Apr 14, 2016 at 8:41
  • Right. I thought you needed to persist data in android's app.. If so, the data you store in Android should be the native app data model instead of webservices data model. Otherwise you will need to translate it for every query you do to your little db in order to make it fit in UI. Point is let client app to have its own data model and just keep update the transformers (drivers) between client and server.
    – Laiv
    Commented Apr 14, 2016 at 18:18
  • @Sushant I edit my answer. I wrote down a brief description. Hope it helps. Some subjects are hard to me to explain properly in english :-)
    – Laiv
    Commented Apr 14, 2016 at 18:45
  • thank you so much such a nice answer. Suppose there is a need for syncing client and server data instead of just caching data, in that case what strategy should we use?
    – Sushant
    Commented Apr 19, 2016 at 3:51
  • It depends on the volume of the data. In my current project, the iPad is storing the insane smount of 400Mb... The sync is a project by itself. Such sync need to be paginated and filtered by timestamp. We do deltas. However the data model at client And server side follows what we have been talking in this post ;-). The very same strategy
    – Laiv
    Commented Apr 19, 2016 at 4:52

You are close with your first point, but I think a better approach is:

  • Design your data model (not the database schema) with input from as many disparate sources as your project can fund. You need the opinions of developers, architects, testers, users and business analysts. You might use a UML tool, but many projects just use post-its on a large sheet of card. Time spent on this phase of the project will be easily recouped by the lack of rework later in the project.
  • From the data model, design the database schema, the service operations required, and the UI screens. At this stage you can allocate a small team to each task.
  • Start coding.

As all the developers now have the same understanding of the business domain, all the pieces should integrate without problem.

Don't be afraid of apparent complexity in the data model - just make sure it accurately reflects reality. Code complexity is easy to deal with if you got the model design correct.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.