1. Controllers
2. Repository/Data Access Layer
   1. 5. Query Database
   2. Models map to Tables
   3. Data Context Database
3. Logic
   1. Optional Layer between Controller and DAL
      1. Can be Very Complex
      2. Or a simple Adaptor Pattern
   2. 3 Process Actions
   3. 7. Data ready for return
4. Razor Views
5. View Models
   1. Hold Data for particular views
   2. Lightweight
6. User REST request
7. Logic (Instantiates DAL Interface)
   1. Calculate(x,y)
      1. DAL.Get(x)
      2. DAL.Get(y)
   2. Retrieve(something)
      1. DAL.Get(something)
   3. Delete(something)
      1. Dal.Delete(something)
   4. New()
8. Data Access Layer (Instansiates DB Interface)
   1. Get()
   2. Delete()
   3. Query
   4. Add()
9. Controller (Instantiates logic interface)
   1. Create
      1. logic.New()
   2. Read
      1. logic.Retrieve()
   3. Update
      1. logic.Update()
   4. Destroy
      1. logic.Delete(x)
10. More Layers
    1. DBContext
    2. Model Entities
11. Why have ViewModels?
    1. Pros and Cons
    2. Pros
       1. Neat looking code
       2. Logic returns predictable data model
       3. Programmer has less to think about
    3. Cons
       1. You can't always fit all data neatly together
       2. May not need all data initially
    4. Alternatives
       1. Simple requests may directly use model entities
       2. Pass individual variables in ViewBag or ViewData
       3. Use JavaScript to request JSON via REST API
12. REST % CRUD == 0
    1. Ideally, one web resource has 4 user actions
    2. Create, Read, Update, Destroy
    3. REST is how the URL is structured to achieve CRUD
    4. Pros
       1. CRUD maps nicely to SQL actions
       2. Enforcing CRUD Keeps Code Simple
       3. Forces Programmer to think of User Tasks
       4. User Centered Design?
       5. The View can stay simple and dumb
    5. Cons
       1. You could need many controllers if strictly keeping each controller to one task
       2. Not all user actions need CRUD on resources.. e.g. simple static pages
       3. It can be impossible to map one user task to only one resource..
          1. e.g. Order Pizza action:
          2. new order
          3. new payment
          4. payment confirmation
       4. Simple actions may not require all 4 actions
       5. We may also want another MVC layer in the View itself.. difficulty in communication between 2 MVCs?
13. Low Coupling
14. Program to Interface,
15. Seperate
16. not to Specific Objects
17. Abstraction