These patterns provide an elegant way of coding triggers to avoid bad practices such as repetitive SOQL queries that can hit governor limits and multiple triggers over the same object. The patterns enforce a logical sequence to the trigger code and in turn help to keep code tidy and more maintainable. Keeping trigger logic for each object in a single place avoids problems where multiple triggers are in contention with each other and makes it easier to debug. Enforcing up front caching of data within a trigger keeps the trigger 'bulkified' and avoids those nasty 'too many SOQL queries'.

Opportunity Trigger:trigger AccountTrigger on Opportunity(after delete, after insert, after update, before delete, before insert, before update) {TriggerFactory.createHandler(Opportunity.sObjectType);}

The @ReadOnly annotation allows you to perform unrestricted queries against the Force.com database. All other limits still apply. It's important to note that this annotation, while removing the limit of the number of returned rows for a request, blocks you from performing the following operations within the request: DML operations, calls to System.schedule, calls to methods annotated with @future, and sending emails.

Only WebService, RemoteAction, or Schedulable.execute() methods can be marked read-only.

Campaign Influence in Salesforce is used to associate multiple influential campaigns to a single opportunity.

View influential campaigns from the Campaign Influence related list on the opportunity detail page. The Primary Campaign Source field on an opportunity detail page allows you to designate the most influential campaign for that opportunity.

1. Go to Customize --> Campaigns --> Campaign Influence.

2. Save the Campaign Influence.

3. You can add campaigns to Opportunities using Campaign Influence related list.

Custom metadata is customizable, deployable, packageable, and upgradeable application metadata. First, you create a custom metadata type, which defines the form of the application metadata. Then you build reusable functionality that determines the behavior based on metadata of that type. Similar to a custom object or custom setting, a custom metadata type has a list of custom fields that represent aspects of the metadata. After you create a public custom metadata type, you or others can declaratively create custom metadata records that are defined by that type. When you package a public custom metadata type, customers who install the package can add their own records to the metadata type. Your reusable functionality reads your custom metadata and uses it to produce customized application behavior.

Custom metadata rows resemble custom object rows in structure. You create, edit, and delete custom metadata rows in the Metadata API or in Setup. Because the records are metadata, you can migrate them using packages or Metadata API tools. Custom metadata records are read-only in Apex and in the Enterprise and Partner APIs.

Custom Metadata Types are similar to Custom Settings. Let's see an example to use it in Salesforce.