2010-12-06 19 views
25

¿Cuál es la diferencia entre una capa de servicio y un repositorio? He trabajado en muchas aplicaciones demo de ASP.NET MVC y la mayoría de ellas solo tienen repositorios. Y algunos tienen una mezcla de ambos. ¿Cuándo utiliza repositorios simples y cuándo usa servicios/o ambos? Lo mismo es cierto para las aplicaciones web ASP.NET.Service ASP.NET vs capas de repositorio

Respuesta

29

repositorios actúan igual que las puertas de enlace a su almacenamiento de datos (base de datos SQL, archivo XML, etc.) mientras que los servicios por lo general por lo implementan Me reglas comerciales sobre sus datos antes de enviar los datos a guardar en la base de datos a través de un repositorio.

Considere este ejemplo:

class UserRepository : IUserRepository 
{ 
    public void Create(User userToCreate) 
    { 
     //update tracking and save to repository 
     _userToCreate.DateCreated = DateTime.Now; 
     _dataContext.AddNew(userToCreate); 
    } 
} 


class UserService : IUserService 
{ 
    private IUserRepository _repository; 

    public UserService(IUserRepository repository) 
    { 
     _repository = repository; 
    } 

    public void Create(User createdByUser, User userToCreate) 
    { 
     //implement some business rules 
     if(!createdByUser.HasRights(UserRights.CanCreateNewUser)) 
      throw new Exception("This user '"+createdByUser.Name+"' does not have the rights to create a new user"); 

     //update rules auditing 
     _userToCreate.CreatedByUserId = createdByUser.Id; 

     //save entity to repository 
     _repository.Create(userToCreate); 
    } 
} 

Luego, en su acción de controlador que va a utilizar el servicio directamente, donde se pueden aplicar todas las reglas de negocio. De esta forma, puede probar sus controladores, reglas comerciales (servicios) y persistencia (repositorios) por separado/de forma independiente utilizando simulaciones.

public ActionResult CreateUser(User newUser) 
    { 
     if(ModelState.IsValid) 
     { 
      _userService.Create(this.CurrentUser, newUser); 
      if(newUser.Id > 0) 
       return RedirectToAction("UserCreated"); 
     } 
     return View(newUser); 
    } 
+0

¿La capa de servicio siempre tendrá un nombre de método correspondiente en el repositorio? –

+3

No necesariamente. Considere el Repositorio como un grupo de consultas. Por ejemplo, la capa de repositorio puede tener ** IQueryable GetUsers ** pero la capa de servicio puede tener más métodos que usan solo esta misma consulta. p.ej. ** IList GetUsers (int companyId, int pageNo) **, ** Usuario FindUser (int companyId, string name) **, ** bool HasUsers (companyId) ** etc. – Tawani

+1

Me gusta la noción de que la capa de servicio maneje la lógica de negocios, eliminándola de los métodos/controladores de acción. Gracias por las sugerencias de Tawani. – beaudetious

13

Un repositorio normalmente solo maneja el acceso a datos. Una capa de servicio usará un repositorio y aplicará cualquier lógica comercial adicional. Piense en el repositorio como una capa reutilizable que podría ser utilizado por cualquier cosa que quiera acceder a sus datos. Diferentes aplicaciones pueden tener diferentes reglas de negocio (que iría en la capa de servicio), pero todos podían usar la misma capa implmentation repositorio

+0

¿Dónde colocarías tus repositorios y servicios? ¿Cómo es tu estructura de proyecto? Tengo MyProject.BusinessObjects y MyProject.DataObjects. Actualmente tengo mis repositorios en MyProject.BusinessObjects. –

+1

me gusta poner mi modelo de dominio (entidad marco edmx, por ejemplo) y las clases de repositorio en un proyecto independiente MyProject.Data. Usualmente mis servicios viven dentro del proyecto MVC Web App, en una carpeta/Services (pero no necesariamente consideraría una mejor práctica, solo una preferencia personal) – kenwarner

+0

@qntmfred: La lógica de negocios de datos debe estar en el mismo proyecto que MyProject .Data, de lo contrario terminaría duplicando la lógica comercial en las aplicaciones web que dependen del proyecto MyProject.Data. – Alkaline