What is the best way to structure an apex trigger?

Question

I'm curious between Version 1 and Version 2, which of these trigger structures is more efficient? Or is there is another structure that is better?

When using a for loop I can check requirements of the record that is causing the trigger to fire. Such as making sure the picklist contains the right value or that a field is not empty. For this case is Version 1 or 2 preferred?

If there is a choice, is it better to work with a list(version 3) or an individual record(version 1 and 2)?

Version 1

trigger AcctTrigger on Account(before insert, before update) 
{
    for(Account a : trigger.new)
    {
       if(trigger.isBefore && trigger.isInsert)
       {
          //call handler(a)
       }
       if(trigger.isBefore && trigger.isUpdate)
       {
          //call handler(a)
       }
    }
}

Version 2

trigger AcctTrigger on Account(before insert, after insert, after update) 
{
   if(trigger.isBefore && trigger.isInsert)
   {
      for(Account a : trigger.new)
      {
         //call handler(a)
      }
   }
   if(trigger.isBefore && trigger.isUpdate)
   {
      for(Account a : trigger.new)
      {
         //call handler(a)
      }
   }
}

Version 3

trigger AcctTrigger on Account(before insert, before update) 
{
    if(trigger.isBefore && trigger.isInsert)
    {
       //call handler(trigger.new)
    }
    if(trigger.isBefore && trigger.isInsert)
    {
       //call handler(trigger.new)
    }
}

Answer 1

You could use the newer Trigger.operationType enum.

trigger AcctTrigger on Account(before insert, after insert, after update) {
    switch on Trigger.operationType {
        when BEFORE_INSERT, BEFORE_UPDATE {
            // call your before handler
        }
        when AFTER_INSERT {
            // call your after handler
        }
        when else {
            // this shouldn't happen
        }
    }
}

Answer 2

Of the three structures shown here, only Version 3 is best practice. Your trigger should never iterate over context variables and call handler methods with single sObjects, because this makes it impossible for your handler to be meaningfully bulkified.

That said, there are two superior patterns. One is what Charles articulated, using a switch on statement with Trigger.operationType. The other is to use a trigger handler framework that abstracts away the dispatch operation, so that you do not repeat the same boilerplate logic in each trigger. Kevin O'Hara's trigger framework, for example, moves all dispatch logic into the trigger handler base class, so you don't need to see or write it.