¿Mi aplicación ASP.NET MVC está estructurada correctamente?

Question

He estado revisando los tutoriales (específicamente los que usan Linq-To-Entities) y entiendo los conceptos básicos, sin embargo, algunas cosas me están dando problemas.

Los tutoriales generalmente involucran solo modelos y formularios simples que solo utilizan declaraciones básicas de creación, actualización y eliminación.Los míos son un poco más complicados y no estoy seguro de hacerlo de la manera correcta porque cuando llega el momento de manejar las relaciones de media docena de objetos de base de datos, los tutoriales dejan de ayudar.

Para el método post, la forma habitual de realizar operaciones CRUD.

entities.AddToTableSet(myClass);
entities.SaveChanges();

No haré lo que quiero porque una clase completamente implementada no se publica en el método del controlador.Puedo publicar campos individuales, colecciones de formularios o múltiples objetos DTO y luego llamar a un método en un servicio o repositorio para tomar la información que recibo de una publicación de formulario, junto con la información que necesita consultar o crear por sí mismo, y luego desde Todas esas cosas, creo mi objeto de base de datos que puedo guardar.

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Add(int id, [Bind(Exclude = "Id")] ClassA classA,
                        [Bind(Exclude = "Id")]ClassB classB)
{
   // Validation occurs here

   if(!ModelState.IsValid)
      return View();

   try
   {
      _someRepositoryOrService.Add(id, classA, classB);
      return RedirectToAction("Index", new { id = id });
   }
   catch(Exception ex)
   {
      // Logging and exception handling occurs here
   }
}


public void Add(int id, ClassA classA, ClassB classB)
{
    EntityA eA = new EntityA
    {
        // Set a bunch of properties using the two classes and
        // whatever queries are needed
    };

    EntityB eB = new EntityB
    {
        // Set a bunch of properties using the two classes and
        // whatever queries are needed
    };

    _entity.AddToEntityASet(eA);
    _entity.AddToEntityBSet(eB);
    _entity.SaveChanges();
}

¿Estoy manejando esto correctamente o estoy bastardeando el marco?En realidad, nunca uso un objeto de entidad directamente; cada vez que consulto uno, coloco la información que necesito en un DTO y baso mis Vistas en eso.Lo mismo ocurre con la creación.¿Está esto permitido o mi evitación del uso de entidades va directamente en contra del propósito de usar el marco?

Editar:También me preocupa este enfoque porque requiere constructores vacíos para realizar correctamente las consultas LINQ debido a este mensaje de error:

Solo los constructores sin parámetros y los inicializadores se admiten en LINQ to Entidades.

Esto no es un gran problema ya que rara vez necesito lógica en los constructores, pero ¿es un problema no tener constructores y solo propiedades públicas?

Answer 1

_someRepositoryOrService.Add(id, claseA, claseB);

Yo diría que combine sus repositorios con la capa de presentación.Esto no debería ser así.Sus repositorios solo deberían funcionar con entidades.A continuación, observe cómo su método Add

Agregar vacío público (int id, ClaseA claseA, ClaseB claseB)

rompe la separación de preocupaciones (SoC).Realiza dos tareas:

1. mapear datos de vista en entidades
2. guardar en el repositorio

Obviamente el primer paso se debe realizar en la capa de presentación.Considere usar carpetas de modelos para esto.También puede ayudarle a resolver el problema de los constructores, ya que sus carpetas de modelos pueden conocer los requisitos de construcción.

Mira también este excelente correo por Jimmy Bogard (coautor de ASP.NET MVC In Action) sobre ViewModels.Esto podría ayudarle a automatizar el mapeo.También sugiere una técnica inversa: ¡haga que sus controladores funcionen con entidades, no con ViewModels!Los filtros de acciones personalizados y carpetas de modelos son realmente la clave para eliminar rutinas que en realidad no pertenecen a los controladores sino a un detalle de infraestructura entre la vista y el controlador.Por ejemplo, aquíAsí es como automatizo la recuperación de entidades. AquíAsí es como veo lo que deberían hacer los controladores.

El objetivo aquí es hacer que los controladores se contenten con la gestión de la lógica empresarial, dejando de lado todos los detalles técnicos que no pertenecen a su negocio.En esta pregunta hablas de restricciones técnicas y dejas que se filtren en tu código.Pero puede utilizar herramientas MVC para trasladarles el nivel de infraestructura.

ACTUALIZAR:No, los repositorios no deberían manejar datos de formularios, a eso me refiero con "acoplamiento con presentación".Sí, los repositorios están en el controlador, pero no funcionan con datos de formulario.Puede (no es que deba) hacer que el formulario funcione con "datos de repositorios", es decir,entidades, y eso es lo que hacen la mayoría de los ejemplos, p.NerdDinner, pero no al revés.Esto se debe a la regla general: las capas superiores se pueden combinar con las inferiores (presentación combinada con repositorios y entidades), pero nunca los niveles bajos deben combinarse con los superiores (las entidades dependen de los repositorios, los repositorios dependen del modelo de formulario, etc. ).

El primer paso debe realizarse en el repositorio, así es, excepto que el mapeo de ClassX a EntityX no pertenece a ese paso.Es una preocupación cartográfica: una infraestructura.ver por ejemplo este pregunta sobre el mapeo, pero en general, si tiene dos capas (UI y repositorios), no deberían preocuparse por el mapeo; un servicio/ayudante de mapeo debería hacerlo.Además del blog de Jimmy, también puedes leer ASP.NET MVC en acción o simplemente mirar su Servidor CodeCamp para saber cómo realizan el mapeo con las interfaces IEntityMapper pasadas a los constructores de controladores (tenga en cuenta que este es un enfoque más manual y que requiere menos trabajo que el AutoMapper de Jimmy Bogard).

Una cosa más.Lea sobre Domain Driven Design, busque artículos, aprenda de ellos, pero no es necesario que lo siga todo.Estas son pautas, no soluciones estrictas.Vea si su proyecto puede manejar eso, vea si usted puede manejar eso, y así sucesivamente.Intente aplicar estas técnicas, ya que generalmente son formas excelentes y aprobadas de realizar desarrollo, pero no las tome a ciegas: es mejor aprender en el camino que aplicar algo que no comprende.

Answer 2

Yo diría utilizando dtos y envolviendo el marco de la entidad con sus propios métodos de acceso de datos y la capa de negocio es un gran camino por recorrer. Usted puede terminar de escribir un montón de código, pero es una arquitectura mejor que pretender que el código generado Entity Framework es su capa de negocio.

Estos problemas no son realmente necesariamente ligados a ASP.NET MVC de ninguna manera. ASP.NET MVC da básicamente ninguna orientación sobre cómo hacer su modelo de acceso / datos y la mayoría de las muestras y tutoriales para ASP.NET MVC no son dignos de producción implementaciones modelo, pero en realidad sólo muestras mínimas.

Parece que estás en el camino correcto, seguir adelante.

Al final, está utilizando Entity Framework en su mayoría como un generador de código que no está generando código muy útil y lo que es posible que desee ver en otros generadores de código o herramientas o marcos que responden más a sus necesidades.