Creating a client side database to store consumed web services?

Question

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?

Answer 1

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.

Summaraizing

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

Edit:

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.

Client-side:

• 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.

Answer 2

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.