¿Cómo se puede crear una aplicación ASP.Net MVC con EF?

Question

Tengo problemas para conceptualizar cómo diseñar una aplicación MVC con Entity Framework en una aplicación n-tiered.

El, libro de texto de aplicación de 3 niveles normales debería ser algo como

Data Access-> Negocios lógica-> Presentación

La presentación no debe saber nada sobre el acceso a los datos. Con EF, TODAS las capas necesitan saber sobre el modelo. Así que mi arquitectura ahora se parece más a

Data Access->Business Logic 
    |    | 
     --------------- 
      | 
      MVC 

Me estoy perdiendo algo aquí o estoy pensando en esto de la manera incorrecta?

¿Debería estar pensando en EF como la capa de acceso a los datos y poner las entidades en la lógica comercial?

Answer 1

Bueno, supongo que su pregunta es, cómo diseñar "capas" en la aplicación MVC. Eche un vistazo a esta arquitectura simple, la utilizo para mis aplicaciones MVC y parece ser limpia y eficiente.

1. proyecto en la solución - modelo de negocio - biblioteca de clases simple llena de clases de POCO que representan el dominio comercial. Aquí puede usar la anotación de datos, las clases de metadatos para la lógica de validación, etc.

2. proyecto - Depósitos basados ​​en EF - otra biblioteca de clases simple; aquí está el contexto definido (primero el código EF es genial, pero primero puedes usar la base de datos EF o el modelo; solo tienes que agregar la plantilla POCO T4 a la biblioteca de clases de modelo de negocio, no es gran cosa) y un conjunto de clases - repositorios

3. proyecto - por lo general lo llamo "ServiceLayer" más o menos (estoy abierto a sugerencias para un mejor nombre :) - contiene solo interfaces, para repositorios y otros servicios (implementados en proyectos separados) que mi MVC (o cualquier otra tecnología)) uso basado en la aplicación; repositorios de 2.project implementan estas interfaces

4. proyecto - sitio web de MVC. Utiliza la inyección de dependencia (compilación en DependencyResolver, y me encanta usar el contenedor Ninject) para mapear repositorios (y otros servicios); A continuación, puede utilizar la inyección de constructor en los controladores, o algún enfoque "perezosa" (véase más adelante)

se ve algo como esto:

controlador flaco:

 
public class SomethingController : BaseController 
{ 
    public ActionResult DoSomething(SomeBusinessThing input) 
    { 
     if (ModelState.IsValid) 
     { 
      var result = CustomerRepository.DoSomeBusinessLogicAndPersistenceAndStuff(input); 
      return View(result); // you can use AutoMapper here, if you dont want to use business object as viewmodels 
     } 
    } 
} 

Mi repositorio "propiedad "es heredado de mi BaseController:

 
public class BaseController : Controller 
{ 
    // ... other stuff used by all (or multiple) controllers 

    private ICustomerRepository _customerRepository; 
     protected ICustomerRepository CustomerRepository 
     { 
      get 
      { 
       if (_customerRepository== null) 
        _customerRepository= DependencyResolver.Current.GetService(); 
       return _customerRepository; 
      } 
     } 
} 

Puede usar este DI" perezoso "si su el controlador usa muchos servicios, pero solo 1-2 por acción, por lo que sería poco eficiente inyectarlos a todos con el constructor.Alguien podría decir que estás "ocultando" la dependencia de esta manera, pero si mantienes todo esto en un solo lugar, BaseController, no es gran cosa.

Bueno, la implementación del repositorio es realmente su negocio. aplicación MVC incluso no sabe que está utilizando EF, que no conoce más que las interfaces de servicios, y no le importa acerca underlaying aplicación

Conslusion (que se puede cambiar en cualquier momento posterior si es necesario!):

• Los controladores son delgados - no hay lógica comercial

• El modelo es FAT - y en este caso, los repositorios encapsulan toda la lógica comercial (puede usar otros tipos de servicios, por ejemplo algunas calculadoras para procesamiento, etc.) , A MVC no le importa, sabe todo Interfaces y)

• ViewModels son entrada para Vistas (y modelo de vista puede ser su modelo de negocio directamente, o puede utilizar AutoMapper para crear ViewModels "puros")

Answer 2

Puede considerar sus entidades EF como objetos de datos y tener modelos de vista separados que se pasan a las vistas. Los datos de sus objetos EF se pueden usar para completar los modelos de vista (las bibliotecas como AutoMapper son útiles aquí). De esta forma, sus vistas nunca tienen una dependencia directa de los objetos EF, solo en sus modelos de vista.

Answer 3

puedo recomendar realmente bueno (me pensar) sobre el diseño de arquitectura impulsado por dominio en la plataforma .NET. Libro si se llama guid de arquitectura de dominio en capas N con .NET 4.0. En el libro se explica cómo crear una buena arquitectura con EF y MVC (y muchas otras cosas como Silverlight, IoC con Unity, etc.).

libro se puede descargar en esta dirección:

http://msdn.microsoft.com/es-es/architecture/en/

Además aplicación de la muestra es muy interesante:

http://microsoftnlayerapp.codeplex.com/

mejor manera de cómo crear entidades de EF es la creación de clases POCO independientes en la capa persistente Estas entidades de dominio están incluidas en la capa lógica de Dominio (Negocio).

En el libro también se explica que la aplicación se debe dividir en más capas, explicando Presentación, Aplicación, Dominio, Infraestructura (persistencia de datos principalmente), capas de servicios Transversales y Distribuidas.