### tl;dr

In a good design. Should accessing the database be handled in a separate business logic layer (in an asp.net MVC model), or is it OK to pass `IQueryable`s or `DbContext` objects to a controller? 

Why? What are the pros and cons of each?

---

I'm building an ASP.NET MVC application in C#. It uses [EntityFramework](https://stackoverflow.com/tags/entity-framework/info) as an ORM.

Let's simplify this scenario a bit.

I have a database table with cute fluffy kittens. Each kitten has a kitten image link, kitten fluffiness index, kitten name and kitten id. These map to an EF generated POCO called `Kitten`. I might use this class in other projects and not just the asp.net MVC project.

I have a `KittenController` which should fetch the latest fluffy kittens at `/Kittens`. It may contain some logic selecting the kitten, but not too much logic. I've been arguing with a friend about how to implement this, I won't disclose sides :)

### Option 1: db in the controller:

```
public ActionResult Kittens() // some parameters might be here
{
   using(var db = new KittenEntities()){ // db can also be injected,
       var result = db.Kittens // this explicit query is here
                      .Where(kitten=>kitten.fluffiness > 10) 
                      .Select(kitten=>new {
                            Name=kitten.name,
                            Url=kitten.imageUrl
                      }).Take(10); 
       return Json(result,JsonRequestBehavior.AllowGet);
   }
}

```

### Option 2: Separate model

```
public class Kitten{
   public string Name {get; set; }
   public string Url {get; set; }
   private Kitten(){
        _fluffiness = fluffinessIndex;
   }

   public static IEnumerable<Kitten> GetLatestKittens(int fluffinessIndex=10){ 
        using(var db = new KittenEntities()){ //connection can also be injected
            return db.Kittens.Where(kitten=>kitten.fluffiness > 10)
                     .Select(entity=>new Kitten(entity.name,entity.imageUrl))
                     .Take(10).ToList();
        }
    } // it's static for simplicity here, in fact it's probably also an object method
      // Also, in practice it might be a service in a services directory creating the
      // Objects and fetching them from the DB, and just the kitten MVC _type_ here

}

```

```
//----Then the controller:
public ActionResult Kittens() // some parameters might be here
{
    return Json(Kittens.GetLatestKittens(10),JsonRequestBehavior.AllowGet);
}

```

Notes: `GetLatestKittens` is unlikely to be used elsewhere in the code but it might. It's possible to use the constructor of `Kitten` instead of a static building method and changing the class for Kittens. Basically it's supposed to be a layer *above* the database entities so the controller does not have to be aware of the actual database, the mapper, or entity framework. 

* **What are some pros and cons for each design?**
* **Is there a clear winner? Why?**

Note: Of course, alternative approaches are *very* valued as answers too.

**Clarification 1:** This is *not* a trivial application in practice. This is an application with tens of controllers and thousands of lines of code, and the entities are not only used here but in tens of other C# projects. The example here is a *reduced test case*.