While defining data to be exchanged between the Service layer and its callers, keep in mind that the responsibility of the Service layer is to be caller-agnostic. Unless you're explicitly developing functionalities for such data formats, avoid returning information through JSON or XML strings; allow the caller (for example, a JavaScript remoting controller) to deal with these kinds of data-marshaling requirements.

As per the guidelines, using inner classes is a good way to express and scope data structures used by the Service methods; the following code also illustrates a bulkified version of the multi-parameter non-bulkified method shown in the previous section.

Take a look at the following code:

public with sharing class ContestantService { 
 
  public class RaceRetirement{ 
  public Id contestantId; 
    public String reason; 
  } 
 
  public static void retireFromRace(
      List<RaceRetirement> retirements) { 
    // Process race retirements...  
  } 
} 

Always keep in mind that the Service method really only needs the minimum information to do its job, and express this through the method signature and related types so that callers can clearly see that only that information is required or returned. This avoids doubt and confusion in the calling code, which can result in it passing too little or redundant information.

The preceding example utilizes read and write member variables in the RaceRetirement class, indicating both are required. The inner class of the RaceRetirement class is only used as an input parameter to this method. Give some consideration before using an inner class, such as both input and output types, since it is not always clear which member variables in such classes should be populated for the input use case or which will be populated in the output case.

However, if you find such a need for the same Apex type to be used as both an output and input parameter, and some information is not required on the input, you can consider indicating this via the Apex property syntax by making the property read-only. This prevents the caller from populating the value of a member field unnecessarily; for example, consider the following Service methods in the RaceService method:

public static Map<Id, List<ProvisionalResult>>
  calculateProvisionalResults(Set<Id>raceIds)  
{ 
  // Implementation  
} 
 
public static void applyRaceResults(
   Map<Id, List<ProvisionalResult>> provisionalResultsByRaceId) 
{ 
  //Implementation 
} 
 
public class ProvisionalResult{ 
  public Integer racePosition {get; set;} 
  public Id contestantId {get; set;} 
  public String contestantName {get; private set;}  
} 

While calling the calculateProvisionalResults method, the contestantName field is returned as a convenience but is marked as read-only since it is not needed when applied in the context of the applyRaceResults method.