You can absolutely use an before trigger for that and it will work. That said, I typically leave the before trigger to the simpler functionality. IMO, updates to and validations against the records being acted on should happen in the before trigger, most everything else like cross object logic and callouts/emails/etc. should happen after. But there is nothing that says you can't create records before if you desire.
In a Before Trigger, Trigger.new and Trigger.old both contain the same values. However, in a Before Trigger, one can operate on the values in Trigger.new and change their values.
In an After Trigger, Trigger.new will contain the the Id's and field values of any records that have been changed by a DML operation. The values contained in Trigger.new can be compared to Trigger.old in order to determine which records meet the criteria for firing the trigger and need to be operated on. Unlike in a Before Trigger, the values in Trigger.new cannot be changed or edited.
Recursion is frequently handled by setting a boolean static variable to "true" when a trigger initially fires. Upon entry to the trigger, that static variable is tested. If the boolean is "true" when re-entered in the same execution context, then the trigger is exited rather than allowing it to run again. There are a variety of methods for handling recursion and this is probably the most common.
Edit
I think what you're looking for are trigger patterns such the one described by Dan Appleman in his book Advanced Apex Programming for Salesforce and Force.com (Note: sample code available from App Exchange as an unmanaged package), Hari Krishan's Architecture Framework to Handle Triggers or Kevin O'Hara's Trigger Framework among others that exist or have been espoused which you can find through searching that go beyond the Trigger Pattern for Tidy, Streamlined, Bulkified Triggers.
Using a Main Dispatcher class, these approaches take charge of trigger execution, extending it to an enterprise level application that's scalable, can have it's own diagnostics classes and error reporting, utilize common helper classes and much more. One can also control trigger execution order; something that can't be done with triggers that operate independently of one other without some kind of central control for each object or, as is the case with some architures, potentially for related objects as well.
Discussing them in depth is beyond the scope of this forum, but I'll point you to at least a few posts that you may find relevant including: Controlling Trigger Execution, One Trigger Approach: Any Logic in Trigger?, Difficulties with Appleman's Trigger Classes and General trigger bulkification - best practices.
Best Answer
Field updates should always go in the
before
context. Putting themafter
requires further DML, which has a host of complications. If you need to query for related records, you can query those tables by Id instead.You may also want to look into some best practices like Trigger Handler pattern, and Filter Layer as well.