Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
Full Getter Methods entry
How-to guide

Write a clean getter on a Visualforce controller

The shortest path is the property syntax with a private backing field and an explicit lazy-load check. The pattern handles 90 percent of controller getter needs.

By Dipojjal Chakrabarti · Founder & Editor, Salesforce DictionaryLast updated May 21, 2026

The shortest path is the property syntax with a private backing field and an explicit lazy-load check. The pattern handles 90 percent of controller getter needs.

  1. Declare the backing field as private

    private Account cachedAccount; The field holds the loaded value across multiple getter calls inside the same controller instance.

  2. Add the property with a custom get block

    public Account currentAccount { get { if (cachedAccount == null) cachedAccount = [SELECT Id, Name FROM Account WHERE Id = :recordId LIMIT 1]; return cachedAccount; } private set; }

  3. Reference the property from Visualforce

    {!currentAccount.Name} on the page now reads through the property; the SOQL runs once even if the expression appears five times.

  4. Invalidate when state changes

    When the controller takes an action that changes the underlying record, set cachedAccount = null inside the action method so the next getter call refreshes the data.

  5. Write the unit test

    Create an Account in the test, instantiate the controller with the record ID, call currentAccount, and System.assertEquals on the returned name.

Mandatory fields
Property/method visibilityrequired

Must be public to be reachable from Visualforce or Lightning bindings.

Return typerequired

Any Apex type; primitive, sObject, or custom class.

Naming conventionrequired

Java-style getX or C#-style property name. Visualforce maps both to the same expression syntax.

@AuraEnabled annotation (Lightning only)required

Required to call the getter from JavaScript; add cacheable=true for read-only methods.

Gotchas
  • Getters with SOQL run on every Visualforce rerender. A page with five expressions referencing five different SOQL-heavy getters can fire 25 queries per render without caching.
  • Side effects inside getters are an anti-pattern. Modifying state, performing DML, or making callouts from a getter breaks the implicit contract that getters are read-only.
  • Lazy-load caching survives only inside the controller instance. Visualforce controllers are recreated on each request; the cache does not persist across requests unless persisted to ViewState.
  • @AuraEnabled cacheable=true methods cannot perform DML. Mark a method cacheable only when it is genuinely read-only.

See the full Getter Methods entry

Getter Methods includes the definition, worked example, deep dive, related terms, and a quiz.