Lightning Data Service (LDS) in Salesforce

If we have a lightning application that Creates, Reads, Updates or Deletes a record (basically CRUD operations) in the Salesforce database, Lightning Data Service (LDS) is the best and most efficient way to do so. By using LDS, we don't have to write Apex controller code to fetch or create data in Salesforce. The code is already implicitly written in LDS, and we only need to call it to use one of the several tools based on our requirements.

Suppose we have several components made to fetch data from the same record, then without LDS, each component would have to make an independent call to the server irrespective of the fact that all these components are fetching information from the same data, hence it reduces efficiency and makes unnecessary calls to the server leading to inconsistencies. Through LDS, we need to fetch record once which reduces network transfers, app server load, and database server load.

Lightning Data service is designed to serve as a data Layer for Lightning Components. It is basically a Lightning Component counterpart of Visualforce Standard Controller, providing access to data displayed on the page. There are several advantages of using Lightning Data Service:

Don't forget to check out: Salesforce Lightning Dialer | Boost Sales productivity by making hassle-free calls

Minimize XMLHttpRequests
LDS eliminates requests that involve the same record data. It sends a single shared data request that updates all the relevant components.
Create notifications when record data changes

Leveraging the tools of Lightning Data Service

Salesforce provides us with the following form-based components:

lightning:recordViewForm
lightning:recordEditForm
lightning:recordForm

In addition to the above mentioned form based LDS tools, Salesforce provides a very versatile components named force:recordData.

lightning:recordViewForm -- We can use this component to view a record data.The fields are rendered with their labels and values which are read only. It requires recordId to display the fields on the record. This component also takes care of Field Level Security and Sharing Settings. To display the fields and values we require, we need to specify them using the inbuilt tag lightning:outputField. Here is an example:

<lightning:recordViewForm recordId="{!v.recordId}" objectApiName="Account">
    <lightning:messages />
    <lightning:outputField fieldName="Name" />
</lightning:recordViewForm>

This example shows an account object record with the Id specified in recordId attribute and field inside the lightning:outputFIeld tag.The RecordId can either be hard-coded or can be obtained from the inbuilt interface for showing a page on the record :

"flexipage:availableForRecordHome, force:hasRecordId"

2. lightning:recordEditForm -- We can use this component to create/edit a record data.The component displays fields with their labels and the current values, and enables us to edit their values. To specify editable fields, we need to use lightning:inputField components inside the lightning:recordEditForm component and lightning:button to save the changes made. Let us see this by an example:

<lightning:recordEditForm recordId="{!v.recordId}" objectApiName="Account">
   <lightning:messages />
   <lightning:inputField fieldName="Name" />
   <lightning:button class="slds-m-top_small" type="submit" label="Create new" />
</lightning:recordEditForm>

This example shows an account object record with the Id specified in recordId attribute and field inside the lightning:inputFIeld tag along with lightning:button to submit it.

3. lightning:recordForm -- Both the tools defined above can be combined into lightning:recordForm component. This can be used to view, create and edit records based on RecordId. The record ID is inherited from the record page via the force:hasRecordId interface. For example:

<lightning:recordForm recordId="{!v.recordId}" 
                              objectApiName="Account"
                              fields="Name" />

In this example, lightning:recordForm displays the account name field and label with a pencil icon, just like how it appears on a record detail page. When the pencil icon is clicked, the field becomes editable with the Cancel and Save buttons shown below it.

4. force:recordData --We can use this component to create,view, edit and delete records. This tool does not inherently include UI elements to show data fetched. We can use it to create highly customization user interfaces beyond what the form-based components provide.It does not contain UI elements. It is just the simple logic fed to the server to fetch relevant data. But for us to be able to view and modify data, we have to use UI elements, for example, lightning:formattedText. Here is the example of the component to load data:

<aura:component>
    <aura:attribute name="recordId" type="String" />
    <aura:attribute name="record" type="Object" />
    <aura:attribute name="simpleRecord" type="Object" />
    <force:recordData aura:id="forceRecordCmp"
recordId="{!v.recordId}"
layoutType="{!v.layout}"
fields="{!v.fieldsToQuery}"
mode="VIEW"
targetRecord="{!v.record}"
targetFields="{!v.simpleRecord}" />
<div class="recordName">
<p class="slds-text-heading--medium">
<lightning:formattedtext title="Record Name" value="{!v.simpleRecord.Name}" /></p>
</div>
</aura:component>

Check out another amazing blog by Anurag here: Best Practices for Data Security in Salesforce

To load a record on the client side, we have to add the force:recordData tag to our component, and set our recordId, mode, and layoutType or fields attributes.

recordId specifies the record to load. Records can’t be loaded without a recordId.
mode can be set to either EDIT or VIEW, which determines the behavior of notifications and what operations are available to perform with the record. If you’re using force:recordData to change the record in any way, set the mode to EDIT.
layoutType specifies the layout (FULL or COMPACT) used to display the record, which determines what fields are included. Using layoutType allows your component to adapt to layout definitions.
fields specifies which fields in the record to query.

The force:recordData tag also supports a set of target attributes, which are attributes that force:recordData populates itself. The target attributes can be used to allow access from the UI.