verdnatura-mirror
/
loopback
mirror of https://github.com/strongloop/loopback.git
0
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

merged in Schoons' changes to mobile clients section

This commit is contained in:
altsang 2013-09-17 16:18:02 -07:00
parent 574abf47a2 315218c79b
commit c136d2995f
1 changed files with 27 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
docs/concepts.md
View File

@ -31,34 +31,36 @@ notifications, register users, and any other behavior provided by data sources.
### Mobile Clients ### Mobile Clients
LoopBack Mobile Client SDKs give mobile developers access to LoopBack provides native Client SDKs to give mobile developers access to remote,
mobile models and services from within their native persistent data in a contextually-relevant way. The transport and marshalling of
development environment and language. the data is taken care of, and mobile developers can leverage all of their
existing tools (XCode, Eclipse, et al) to model their data on the client,
persisting it to the server as needed.
LoopBack SDK's support both predefined static schema's and dynamic To achieve this, LoopBack supports both "Dynamic", schema-less Models and
'schema-less'mobile models. "Static", schema-driven Models. (See ["Models"](#models) for more specifics and
how-tos around Model creation.)
A Dynamic or Schema-less model strategy allows mobile developer to Dynamic Models require minimal server code up front (just a name!) to set-up,
define custom model definitions directly from the SDK that are often with the format of the data specified _completely_ and _flexibly_ by the client
specific to a mobile application needs. Similar to 'Document application. Well-suited for data that _originates on the client_, mobile
Storage' solutions such as Redis or MongoDB. Dynamic models have developers can leverage Dynamic Models to persist data both between sessions and
the added benefit of allowing mobile developers to work with between _devices_ while obviating the need for outside engineering support.
LoopBack as a Mobile back end-as-a-service (mBaaS) without having to (Let's be honest - how many server programmers do you know that are _excited_
predefine the model definition on the server. This strategy is when you ask them to add a field to some schema on the server? None? That's what
often leveraged for data that originates on the mobile device and we thought.)
then persisted in the Mobile backend for later mobile consumption or
server side processing.
Static or traditional schema strategies are also supported in Static Models require more code up front in an extended grammar of JSON we call
LoopBack. A static model configuration promote a consistency in LDL, with the format of the data specified _completely_ in a _structured_ way by
mobile model data and provides easy integration or direct binding to the server application. Well-suited to both existing data and large, intricate
traditional RDBMs such as Oracle and MySQL. The added governance and datasets, mobile developers can leverage Static Models to provide structure and
reliability in providing a 'rigid' model also promotes more robust consistency to their data, preventing the multitude of bugs that can result from
data integrity, validation and standardization. unexpected data in their database. (These pesky bugs _love_ to show up in
production and ruin everyone's launch day. Stop them before they start!)
The ability to leverage either or both strategies in a mobile middle Use one strategy, or use both. Leverage them to fit your _use case_, rather than
tier allows developers to select the best implementation for their fitting your use case to some fixed modelling strategy. The choice is yours.
use case. >>>>>>> 315218c79b59a51b5c3e2d93388ffb65d3510525
### Models ### Models