MVC Design query on Controller/Models

Question

A few queries on EF.

Questions -

1. Should the methods that directly use database context object be part of Controller classes or Models?
2. ContactManagerContext.cs (which I am considering as a DAL layer?) Is my assumption correct?
3. Where should the ContactManager class be placed? Model or DAL? It is currently part of the Model class.
4. will add more questions

This is how I have structured the classes - Models and Controllers.

Please review and comment on if the code is structured correctly or not and how it can be improved.

Model class (Contact.cs):

using Contact_Manager.DAL;

namespace Contact_Manager.Models
{

public class Contact
{
    [Key]
    public int ContactId { get; set; }
    [Required, MaxLength(100)]
    public string FirstName { get; set; }
    [Required, MaxLength(100)]
    public string LastName { get; set; }
    public string EMail { get; set; }
    public string Phone { get; set; }
    public string BusinessName { get; set; }
}

public class ContactManager
{
    ContactContext db = new ContactContext();

    public IEnumerable<Contact> ContactList(int? selectedContact)
    {

        IQueryable<Contact> contacts = db.Contacts;

        return contacts.ToList();

    }

    }
}

ContactManagerContext.cs (DAL)
------------------------------

using System.Data.Entity;
using System.Linq;
using Contact_Manager.Models;


namespace Contact_Manager.DAL
{
    public class ContactContext : DbContext
    {

        public ContactContext()
            : base("ContactMgrDBContext")
        {
            Database.SetInitializer<ContactContext>(new      DropCreateDatabaseIfModelChanges<ContactContext>());
        }

        public DbSet<Contact> Contacts { get; set; }

    }

}

ContactController.cs (Controller class):

using System.Web.Mvc;
using System.Linq;
using Contact_Manager.Models;

namespace Contact_Manager.Controllers
{
    public class ContactController : Controller
    {

        //
        // GET: /Contact/

        public JsonResult ContactList()
        {

            ContactManager cMgr = new ContactManager();

            IEnumerable<Contact> contactList = cMgr.ContactList(0);

            //var contactsJson = JsonConvert.SerializeObject(contacts.ToList());

            return Json(contactList, JsonRequestBehavior.AllowGet);

        }

        public ActionResult Index()
        {
            return View();
        }



    }
}

Answer 1

The MVC pattern is one of the most misunderstood architecture patterns.

Also if it is used very often in UI it is a more general approach. The common usage has to be separated from the aim to adress different responsibilities.

The best way to explain MVC is to see it as a pattern that separates responsibilities AND the collaboration between them in ONE layer. So you may have MVC in the UI-Layer, but also in the DAO-Layer.

For example in the UI-Layer a model object is an object that holds the state of a UI-Component. The View-Object is the UI-Component that holds logic to draw itself on base of the model object state. The Controller retreives events from different sources and orchestrates communication between model and view.

In the DAO-Layer the model object is a part of a database state (often a row). Think of an ORM-Object. The view object is the representation for the "next" layer. The controller is the DAO that orchestrates mappings and changes.

In general you need something that holds a STATE (model). Then you need an external representaion of the STATE to PUBLISH (view) avoiding coupling to the STATE. After all you have to have BEHAVIOUR (controller) orchestrate changes and mappings.

The approach to see MVC as layers may work for small projects. In larger projects you will face problems in maintainability because you have definitely MORE than three responsibilities. And if you only have three layers you will mix responsibilities lacking the Single Responsibility Principle.

To answer your questions:

1. No. Write a separate DAO for that. The controller and/or the model should use that.
2. No. See 1.
3. If we talk about MVC the controller is the controller. Nothing else. If we talk about layers the controller seems to mix responsibilities of UI, Model maybe DAO. So the assignment is ambiguous.

Answer 2

You can you the three Layers' model in the Controller part. the Controller will be the highest layer, and it will "talk" with the BL and so on.

The Models suppose to be simple and clean.