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?
Creating a client side database to store consumed web services?
web services;local storage;dto
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.SummaraizingShould 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 translatorsEdit:Final design would be something like thisServer-side:Back-end: ERMPersistente Layer: ORMBusiness layer: ORM entitiesWebservices:- Controllers: consume ORM entities and transform these into DTO's. DTOs are like webservice data model.Client-side:Webservices client: consumes DTODriver layer: Transform DTO into App's data model.App's business layer: App's data modelApp'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.