Si sus modelos son independientes de la persistencia, ¿cómo los guarda?

Question

Soy nuevo en ASP.NET MVC y tengo experiencia en PHP MVC.Ha sido una transición un tanto incómoda (consulte mi historial de preguntas, je).

Una cosa que me gusta mucho en teoría y que es importante en el mundo .Net es la idea de que los modelos sean independientes de la persistencia.Pero en este caso, ¿cuál es la forma correcta de guardar cambios en un modelo?En PHP, simplemente llamaría $model->save(); después de hacer alguna transformación.En C#, no estoy seguro de cómo hacerlo.

¿Es esto apropiado?

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);
        }
    }
}

Supongo que lo único que me parece incorrecto en esto es que normalmente no quisiera que un controlador acceda directamente a una capa de acceso a datos de esta manera.Anteriormente, en PHP, mis controladores accedían básicamente a modelos y vistas únicamente.

Answer 1

Lo que estás haciendo está bien.ActiveRecord vs Repository vs Home Brew DAL es una cuestión eterna que discutiremos para siempre.

El patrón de repositorio es muy popular en el mundo .NET en este momento y probablemente verá muchos ejemplos de su uso.Sin embargo, a MVC no le importa cuál sea su estrategia de acceso a datos.Usar lo que te resulte cómodo está bien y es una mejor estrategia que usar un patrón porque todos los demás lo hacen.

Answer 2

Está bien que un modelo tenga una función Save(), pero normalmente querrás que el comportamiento de Save() sea independiente de tu modelo, abstraído en una interfaz.

Recuerde sus principios de diseño:diseño a una interfaz, no a una implementación.

Otra advertencia es ¿cómo pruebas tus piezas individualmente?Si un modelo no sabe cómo persiste, se puede probar en función de lo que el modelo debería hacer, y su mecanismo de persistencia se puede probar en función de lo que debería hacer.

En cualquier caso, parece que su acción Create() está cumpliendo una doble función: intentar usar el modelo para guardar y luego intentar usar DataAccess para persistir.¿Estos dos objetos están haciendo lo mismo?¿Podría resultar confuso o ilegible o imposible de mantener más adelante?