Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

369
Views
Patrón de diseño MVC, ¿propósito de la capa de servicio?

Digamos que tengo un patrón de repositorio siguiente:

 interface IGenericRepo<T> where T : class { IEnumerable<T> GetAll(); T GetById(object id); void Insert(T obj); void Update(T obj); void Delete(T obj); void Save(); } interface ICustRepo : IGenericRepo<Cust> { IEnumerable<Cust> GetBadCust(); IEnumerable<Cust> GetGoodCust(); } public class CustRepo : ICustRepo<Cust> { //implement method here }

luego en mi controlador:

 public class CustController { private ICustRepo _custRepo; public CustController(ICustRepo custRepo) { _custRepo = custRepo; } public ActionResult Index() { var model = _custRepo.GetAll(); return View(model); } public ActionResult BadCust() { var model = _custRepo.GetBadCust(); return View(model); } }

Básicamente mi patrón es algo así como

View <-> Controller -> Repo -> EF -> SQL Server

pero vi a mucha gente haciendo esto

View <-> Controller -> Service -> Repo -> EF -> SQL Server

Entonces mi pregunta es:

  1. ¿Por qué y cuándo necesito service layer ? ¿No es solo agregar otra capa innecesaria porque todos los métodos no genéricos ya están implementados en ICustRepo ?

  2. ¿Debería la capa de servicio devolver DTO o mi ViewModel ?

  3. ¿Debería la capa de servicio mapear 1:1 con mi repositorio?

He mirado a mi alrededor durante unos días, pero no estoy satisfecho con las respuestas.

Cualquier ayuda será apreciada y se disculpa por el mal inglés.

Gracias.

ACTUALIZAR :

¿Diferencia entre repositorio y capa de servicio?

Ya he leído esto. Ya sé la diferencia entre esos 2, pero quiero saber por qué y el propósito. entonces eso no responde mi pregunta

over 4 years ago · Santiago Trujillo
2 answers
Answer question

0

TL;DR

  1. Vea la explicación a continuación
  2. Las capas por encima de la capa de servicio no deben ser "conscientes" de que existen más capas por debajo de la capa de servicio.
  3. No necesariamente, porque puede tener, por ejemplo, datos de 1 tipo dispersos en 2 tablas y el "núcleo" solo ve uno, la capa de acceso a datos es responsable de "agrupar" y devolver el tipo de capa de servicio

Explicación

La arquitectura típica de 3 capas se compone de capa de presentación, capa de servicio/dominio, capa de acceso a datos (DAL).

Piense en la capa de servicio como el "núcleo" de su aplicación. Por lo general, la capa de servicio solo tiene interfaces de repositorio que se implementarán en la DAL.

Por lo tanto, le permite cambiar "fácilmente" la forma en que accede a los datos. Los objetos devueltos por la capa de servicio no deberían ser DAO, porque después de todo, la capa de presentación ni siquiera "sabe" que existe DAL.

Escenario: Tiene una Solución de 3 niveles. Actualmente no tiene mucho sentido tener todas las capas.

 /-------------------\ | Web App | <--- Presentation Layer |-------------------| | Service Library | <--- Service Layer |-------------------| | Entity Framework | <--- Data Access \-------------------/

Ahora quiere tener una API REST en ASP.NET MVC WebApi

 /--------------------\ | Web App | REST API | <--- Presentation Layer |--------------------| | Service Library | <--- Service Layer |--------------------| | Entity Framework | <--- Data Access \--------------------/

Ahora, por ejemplo, ya no quiere usar Entity Framework como su acceso a datos y quiere usar NHibernate.

 /--------------------\ | Web App | REST API | <--- Presentation Layer |--------------------| | Service Library | <--- Service Layer |--------------------| | NHibernate | <--- Data Access \--------------------/

Tenga en cuenta que agregamos una nueva forma de presentación y cambiamos la forma en que accedemos a los datos, pero la capa de servicio nunca cambió.

Por lo general, la capa de servicio expone las interfaces que se implementarán en la capa de acceso a datos para que obtengamos la "abstracción" que queremos.

Implementé un proyecto con esta arquitectura en la universidad. Puedes consultar el código AQUÍ

Espero que esto haya ayudado. Lo siento si soy tan aburrido explicando cosas :P

over 4 years ago · Santiago Trujillo Report

0

Ad.1 La capa de servicio debe tener lugar para toda la lógica empresarial. Se trata más de responsabilidades separadas:

  • Controlador - responsable de preparar viewModel y pasar a la vista específica,

  • Repositorio: capa abstracta responsable de recopilar entidades de DB

  • Servicio: responsable de la lógica compleja. A menudo hay casos en que el servicio usa muchas entidades para hacer algo de lógica y devolver solo DTO.

Ad.2 En mi opinión, la capa de servicio debería devolver objetos DTO que deberían asignarse a los modelos de vista en los controladores.

Ad.3 No, este no es el caso. En su ejemplo, puede mover GetBadCust y GetGoodCust del repositorio al servicio y devolver algo de DTO

over 4 years ago · Santiago Trujillo Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!