title: Understanding the new Web API approach
body: <p>I’m aware that not everyone uses a thorough architecture when developing an MVC application but let’s assume I have the following architecture:</p>
  
  <pre><code>App.Core --&gt; Class Library (POCO or Domain objects)
  App.Data --&gt; Class Library (Repository and Entity Framework)
  App.Service --&gt; Class Library (Service layer with all business logic)
  App.Web --&gt; asp.net MVC 3.0 project
  </code></pre>
  
  <hr>
  
  <pre><code>App.Data --&gt; Has a reference to App.Core
  App.Service --&gt; Has a reference to App.Core and App.Data
  App.Web --&gt; Has a reference to App.Core and App.Service
  </code></pre>
  
  <p>Inside our MVC application we try to follows this approach: </p>
  
  <ul>
  <li>Inside our Controller (within a method), we instantiate a ViewModel.</li>
  <li>We fill that ViewModel calling methods from our App.Service Layer</li>
  <li>Once the ViewModel is filled, we return it to the View (so the view
  is now strongly typed).</li>
  </ul>
  
  <p>This occurs 99.9% of the time. It is clean, we like it and it leverages itself pretty well..etc!</p>
  
  <p>Now my question is the following:</p>
  
  <blockquote>
    <p>If we decide to move our application to MVC 4.0 and start using the
    new <strong>Web API</strong> approach, I’m not sure I fully understand where (or how)
    it would fit in our current architecture?</p>
  </blockquote>
  
  <p>Keep in mind, that we are open to change this around!</p>
  
  <p>Should we create a new App.WebAPI layer that sits between the App.Service and App.Web?
  This means inside our Controllers, we would no longer need to call the App.Service directly but instead the new App.WebAPI layer?</p>
  
  <p>Or, leave the Web API inside the App.Web layer and make the Controllers call the other APIControllers which in turn would call the App.Service layer?</p>
  
  <p>Not sure if I make any sense here…but please feel free to suggest anything as I’m curious on different inputs.</p>
  
  <p>Thanks</p>