Question

I am learning asp.net mvc and went through a great tutorial that demonstrated it. The tutorial also used Entity Framework.

We have our own data access class which I have to use.
I am a little bit confused as to what I need to do to bridge the gap between our class and MVC framework.
For example, in the tutorial, inside of MovieController.cs file, there is a Edit method, that looks like this:

[HttpPost]
        public ActionResult Edit(Movie movie)
        {
            if (ModelState.IsValid)
            {
                db.Entry(movie).State = EntityState.Modified;
                db.SaveChanges();
                return RedirectToAction("Index");
            }
            return View(movie);
        }

If I don’t use the Entity framework, what would it look like? Will I still need to use ModelState.IsValid and save the state like it’s done

db.Entry(movie).State = EntityState.Modified;

Please advise. A clearly written example of using asp.net mvc without the use of Entity framework would be great.

What I need to know is what role does state play here and whether it is mandatory to use or is it just a part of how the Entity framework operates.

I would re-write this as:

[HttpPost]
public ActionResult Edit(Movie movie)
{
    myDBObject.SaveChanges();
    return RedirectToAction("Index");

}

Where myDBObject is my custom database access object.

Answer 1

The examples you see out there where controllers use directly some data access framework such as Entity Framework are bad examples. The whole internet is polluted with such stuff. I can hardly look at it without having my eyes hurt. I consider those as bad practices. Data access should be separated and abstracted in a repository. So for example:

public interface IMoviesRepository
{
    Movie Get(int id);
    void Save(Movie movie);
}

then you could have some implementation of this interface using plain ADO.NET, EF, NHibernate, a remote web service call, some custom ORM or really whatever:

public class MyCustomFrameworkMoviesRepository: IMoviesRepository
{
    ...
}

and the controller will take this repository interface as constructor argument:

public class MoviesController: Controller
{
    private readonly IMoviesRepository _repository;
    public MoviesController(IMoviesRepository repository)
    {
        _repository = repository;
    }

    public ActionResult Index(int id)
    {
        var movie = _repository.Get(id);
        return View(movie);
    }

    [HttpPost]
    public ActionResult Index(Movie movie)
    {
        if (!ModelState.IsValid)
        {
            return View(movie);
        }

        _repository.Save(movie);
        return RedirectToAction("Success");
    }
}

and the last part is to configure your dependency injection framework to pass the correct implementation of the repository into the controller. Now as you can see the way the data is fetched is completely decoupled from the controller logic. It is the way it should be. Always try to avoid the strong coupling between the different layers of your application.

And to answer your question about the State property : this is something completely specific to EF, seeing something like this in a controller is a really pity.

And to bring this even further and improve it you would introduce view models. View models are classes which are specifically designed to meet the requirements of a given view. So for example Movie is a domain model. Domain models should never be directly passed to views. Controller actions should never take domain models as action arguments. You should define view models which will contain only what is required by the given view and then perform the mapping between the view models and the domain models. Frameworks such as AutoMapper make this very simple.