Using SObject Repositories

SObjectRepository.cls is one of the core classes of the Nebula framework. This class is intended to handle

• All DML actions for a given SObject type, like insert, update & delete
• All queries for a given SObject type, with the ability to dynamically generate queries and several predefined queries

Note: Typically, there will be 1 class to extend SObjectRepository for each SObject used in your system. For example, if you use the lead object, you will have LeadRepository.cls. Case object is handled by creating CaseRepository.cls, etc. In some more complex systems, having multiple repositories per SObject can also be used.

Using SObject repositories provides several benefits

1. DML actions can be easily altered for your entire codebase
2. Queries, query filters, etc can be dynamically generated
3. Fields can be added & removed declaratively to queries when using field sets
4. All fields on an object can be automatically added to your queries, removing the need to constantly update queries when new fields are added to your SObject. Note: this feature can cause performance issues can occur with large objects, so use carefully.
5. Filter conditions can be easily added to all queries within a repo class by adding filters to your constructor. For example, you can filter out all converted leads for all queries like this

public with sharing class CaseRepository extends SObjectRepository {
    
    public LeadRepository() {
        super(Schema.Lead.SObjectType);
        // Filters in the constructor are applied to all methods in the class
        // This filter means that only leads that have not been converted will be included
        this.Query.filterBy(new QueryFilter(Schema.Lead.IsConverted, QueryOperator.EQUALS, false));
    }

}

Only SObject Type Provided

The most basic implementation can be done by extending SObjectRepository, using just a few lines of code

public with sharing class CaseRepository extends SObjectRepository {
    
    public CaseRepository() {
        // When only an SObject type is provided, all fields for the SObject are included in your queries
        super(Schema.Case.SObjectType);
    }

}

Your new class, CaseRepository.cls, automatically inherits all of the methods in ISObjectRepository.cls and IDML.cls. It also leverages IQueryBuilder methods to dynamically generate queries. Using the super constructor shown above, the framework will automatically include all case fields in every query. If you want to specify the desired fields, you can use either a field set or list of SObject fields.

SObject Type & Field Set Provided

public with sharing class CaseRepository extends SObjectRepository {

    public CaseRepository(Schema.FieldSet myFieldSet) {
         // When a field set is provided, only the fields in the field set are included in your queries
         super(Schema.Case.SObjectType, myFieldSet));
    }

}

SObject Type & List of SObject Fields Provided

public with sharing class CaseRepository extends SObjectRepository {

    public CaseRepository(List<Schema.FieldSet> mySObjectFields) {
        // When a list of SObject fields is provided, only the fields in the field set are included in your queries
        super(Schema.Case.SObjectType, mySObjectFields));
    }

}

Additional Settings

The custome setting Nebula Repository Settings (NebulaRepositorySettings__c) can be used to further control the behavior of the class SObjectRepository.cls.

Note: Nebula's custom settings can be accessed programatically through the class NebulaSettings.

1. Include Common Fields (API Name: IncludeCommonFields__c). If enabled, the following fields are auto-added to your queries if they exist on the SObject. You do not need to add these fields to your field set or list of SObject fields when this option is enabled. This feature can be used with all 3 super constructor's for SObjectRepository.cls
   • Id
   • CaseNumber
   • CreatedById
   • CreatedDate
   • IsClosed
   • LastModifiedById
   • LastModifiedDate
   • Name
   • OwnerId
   • Subject
   • RecordTypeId
   • SystemModStamp
2. Sort Query Fields (API Name: SortQueryFields__c)When enabled, the list of query fields in the dynamic query are sorted when the query is built. For example: SELECT Status, Id, Name FROM Lead becomes SELECT Id, Name, Status FROM Lead