If your models are persistence agnostic, how do you save them?

Question

I'm new to ASP.NET MVC, coming from a PHP MVC background. It's been kind of an awkward transition (see my question history, heh.)

One thing I like a lot in theory that's big in the .Net world is the idea of models being persistence agnostic. But in this case, what is the proper way to save changes to a model? In PHP, I'd just call $model->save(); after doing some transformation. In C#, I'm not sure of how to do that.

Is this appropriate?

public class AwesomesauceController
{
    //inject!
    public AwesomeSauceController(IDataAccess da)
    {
        DataAccess = da;    
    }
    private readonly IDataAccess DataAccess;

    [HttpGet]
    public ActionResult Edit(int Id)
    {
        // PHP equiv: AwesomeSauceModel::find($id); Controller is unaware of DAL
        return View(DataAccess.AwesomeSauces.Where( sc => sc.Id == Id).FirstOrDefault());
    }

    [HttpPost]
    public ActionResult Edit(AwesomeSauce sc)
    {
        //persistence-aware version: model is aware of DAL, but controller is not
         if($sc->valid()
            $sc->save(); 
            redirect(); 
        }
        else { return view(); }

        // compare to persistence-agnostic version, controller is aware of DAL, but model is not
        if(ModelState.IsValid)
        {
            da.Persist(sc);
            return Redirect();
        }
        else
        {
            return View(sc);
        }
    }
}

I guess the only thing that strikes me as wrong about this is that typically, I wouldn't want a controller to be directly accessing a data access layer in this way. Previously, in PHP land, my controllers would access models and views only, basically.

Answer 1

What you are doing is fine. ActiveRecord vs Repository vs Home Brew DAL is an eternal question that we'll discuss forever.

The repository pattern is very popular in the .NET world right now and you'll probably see a lot of examples of its usage. MVC doesn't care what your data access strategy is though. Using whatever you find comfortable is just fine and a better strategy than using a pattern because everybody else is doing it.

Answer 2

It's OK for a model to have a Save() function, but you would usually want that Save() behavior to be independent of your model -- abstracted away to an interface.

Remember your design principles: design to an interface, not an implementation.

Another caveat is how do you test your pieces individually? If a model doesn't know how it's persisted, it can be tested based on what a model should do, and your persistence mechanism can be tested based on what it should do.

In any case, it looks like your Create() action is doing double duty -- trying to use the model to Save, then trying to use the DataAccess to persist. Are these two objects doing the same thing? Could this be confusing or unreadable/unmaintainable later on?