¿Guardar datos en MVC sin Entity Framework?

asp.net asp.net-mvc c# dapper

Pregunta

La mayoría de los ejemplos de MVC que veo parecen usar Entity Framework. Actualmente estoy escribiendo una aplicación MVC que no usará EF (usando Dapper) y me pregunto dónde debería incluir la lógica de persistencia de datos.

Mi primer pensamiento fue colocarlo junto con las clases para mi modelo. Esto significaría que mis clases modelo se verían a continuación:

class User
{
   public int id {get; set;}
   public string name {get; set;}

   Create(string name)
   {
      // dapper to perform insert
   }

   Remove(int id)
   {
     // dapper to perform delete
   }

   //Update(),Delete() etc.
}

Pero no he usado MVC mucho, así que no estoy seguro si esta es una práctica común o no.

¿Es una buena práctica colocar lógica de persistencia de datos en el Modelo o debería tomar un enfoque diferente?

Además, creo que Stack Exchange usa MVC y Dapper . Si alguien sabe en alguna parte que han hablado sobre cómo estructuraron su código, siéntete libre de apuntarme hacia él.

Respuesta aceptada

No esperaría tener que abrir su computadora y presionar un botón en el disco duro para guardar datos en ella, ¿verdad?

Básicamente, el propósito del patrón MVC, y los principios de diseño SÓLIDO en general, es separar sus preocupaciones. Poner la lógica relacionada con guardar, modificar o actualizar su base de datos dentro de su modelo, cuya responsabilidad es ser un objeto que contiene datos, es contrario a la filosofía del patrón al que se supone que debe suscribirse en MVC.

Su controlador es el lugar donde desea realizar la lógica para guardar su información, pero todavía hay una capa de acceso a datos a la que se abstrae la preocupación de interactuar con la base de datos.

Entonces tendrías:

public class MyController {
    IDataAccessLayer _dataAccessLayer;

    public MyController(IDataAccessLayer dataAccessLayer) {
        _dataAccessLayer = dataAccessLayer;
    }
    public ActionResult Create(Model myModel){
        _dataAccessLayer.InsertIntoDatabase(myModel);
        return View();
    }
}

Respuesta popular

Según el diseño de la persistencia de MVC, nunca sea un problema. Puede usar cualquier ORM que desee. Para que el patrón MVC funcione, necesita un Modelo (ViewModel parcial) para visualizar sus datos en la Vista. El controlador manejará su flujo de aplicación.

Ahora desde el controlador puede llamar a cualquier proceso para guardar sus datos.

Creo que puedes usar el patrón Repository con Dapper igual que EF.

Lo principal es tener cuidado de que su aplicación no sea consciente de la persistencia. Puede desarrollar con Dapper y luego también puede proporcionar soporte para EF sin mucho cambio en su nivel de UI.



Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
¿Es esto KB legal? Sí, aprende por qué
Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
¿Es esto KB legal? Sí, aprende por qué