separación de las preocupaciones y el patrón Repositorio de Entity Framework 3.5

Question

Estoy tratando de ser un mejor desarrollador ...

lo que estoy trabajando con:

1. .Net Framework 1.0 MVC
2. Entity Framework 3,5

he estado leyendo y creo que lo que quiero hacer es:

1. Crea un repositorio para cada agregado en el dominio. Un repositorio de órdenes, por ejemplo, administrará los artículos de pedido de un pedido.
2. Crea una capa de servicio para manejar la lógica de negocios. Cada repositorio tendrá un objeto de servicio correspondiente con métodos similares.
3. Crear DTO pasados ​​entre el repositorio y el servicio
4. Posiblemente crear ViewModels que son clases para que la vista consuma.

que tienen una interfaz de repositorio de base que mis interfaces de repositorio agregados implementarán ...

public interface IRepository<T> 
    { 
     IEnumerable<T> ListAll(); 
     T GetById(int id); 
     bool Add(T entity); 
     bool Remove(T entity); 
    } 

Mi Pedido interfaz de repositorio se define de la siguiente manera ... es probable que haya otros métodos como consigo más en este ejercicio de aprendizaje.

public interface IOrderRepository : IRepository<Order> 
{ 
} 

Mis clases de servicio se definen esencialmente de la misma manera que los repositorios, excepto que cada implementación de servicio incluye la lógica comercial. Los servicios tendrán una interfaz de repositorio en el constructor (no estoy listo para IoC en este ejercicio, pero creo que es allí donde me gustaría terminar el camino).

1. Las implementaciones del repositorio se moverán desde la base de datos utilizando Entity Framework. Al recuperar datos; los métodos solo devolverán los DTO y no los objetos generados por EF
2. Los servicios (como los estoy llamando) controlarán el repositorio y llevarán a cabo la lógica comercial. Los servicios son lo que verá en el controlador, es decir _orderService.GetById (1).
3. Aquí es donde comencé a hacer flip-flops y podría utilizar algunos comentarios ... ¿Debería hacer que mis clases de servicio rellenen clases de ViewModel ... no debería tener clases de ViewModel ... tal vez eso es demasiada asignación de un tipo ¿a otro?

Me encantaría obtener algunos comentarios sobre la dirección en que me dirijo con respecto a una separación de preocupaciones.

Gracias

Answer 1

creo que van en la dirección correcta sobre el patrón de repositorio. En cuanto a su pregunta sobre las clases de ViewModel, le sugiero que utilice algo que transforme el resultado de los resultados del método de servicio empresarial en algunos resultados deseados. Por ejemplo, su servicio comercial de pedidos puede tener un método llamado GetOrders(). Usando un atributo personalizado, puede definir el tipo de clase de vista para él. La vista puede obtener el resultado de este método, posiblemente lo una con otros tipos de datos y devuelve el resultado como una colección de objetos con tipos anónimos.En este caso, la vista tomará IQueryable<Order> o IEnumerable<Order> como entrada y devolverá IList como salida.

Este método lo ayudará mucho cuando necesite mostrar diferentes tipos de vistas de sus datos en el lado del cliente. Ya hemos utilizado algo similar (pero más complejo) a este método en el marco de nuestra empresa.