title: How to setup a 3-tier web application project
body: <p><strong>EDIT:</strong>  </p>
  
  <p><em>I have added [MVC] and [design-patterns] tags to expand the audience for this question as it is more of a generic programming question than something that has direclty to do with Python or SQLalchemy. It applies to all applications with business logic and an ORM.<br>
  The basic question is if it is better to keep business logic in separate modules, or to add it to the classes that our ORM provides:</em></p>
  
  <p>We have a flask/sqlalchemy project for which we have to setup a structure to work in. There are two valid opinions on how to set things up, and before the project really starts taking off we would like to make our minds up on one of them.<br>
  If any of you could give us some insights on which of the two would make more sense and why, and what the advantages/disadvantages would be, it would be greatly appreciated.  </p>
  
  <hr>
  
  <p>My example is an HTML letter that needs to be sent in bulk and/or displayed to a single user. The letter can have sections that display an invoice and/or a list of articles for the user it is addressed to.</p>
  
  <hr>
  
  <p><strong>Method 1:</strong><br>
  Split the code into 3 tiers - 1st tier: web interface, 2nd tier: processing of the letter, 3rd tier: the models from the ORM (sqlalchemy).<br>
  The website will call a server side method in a class in the 2nd tier, the 2nd tier will loop through the users that need to get this letter and it will have internal methods that generate the HTML and replace some generic fields in the letter, with information for the current user. It also has internal methods to generate an invoice or a list of articles to be placed in the letter.  </p>
  
  <p><em>In this method, the 3rd tier is only used for fetching data from the database and perhaps some database related logic like generating a full name from a users' first name and last name. The 2nd tier performs most of the work</em>.</p>
  
  <p><strong>Method 2:</strong>
  Split the code into the same three tiers, but only perform the loop through the collection of users in the 2nd tier.  </p>
  
  <p><em>The methods for generating HTML, invoices and lists of articles are all added as methods to the model definitions in tier 3 that the ORM provides. The 2nd tier performs the loop, but the actual functionality is enclosed in the model classes in the 3rd tier</em>.  </p>
  
  <p>We concluded that both methods could work, and both have pros and cons:</p>
  
  <p>Method 1:  </p>
  
  <ul>
  <li>separates business logic completely from database access </li>
  <li>prevents that importing an ORM model also imports a lot of methods/functionality that we might not need, also keeps the code for the model classes more compact.</li>
  <li>might be easier to use when mocking out ORM models for testing</li>
  </ul>
  
  <p>Method 2:</p>
  
  <ul>
  <li>seems to be in line with the way Django does things in Python</li>
  <li>allows simple access to methods: when a model instance is present, any function it
  performs can be immediately called. (in my example: when I have a letter-instance available, I can directly call a method on it that generates the HTML for that letter)</li>
  <li>you can pass instances around, having all appropriate methods at hand.</li>
  </ul>