¿Pasa una referencia de servicio a otra mala práctica de capa de servicio?

Question

Tengo una aplicación C# MVC que rompo la siguiente manera: Ver -> Controlador -> Servicio -> Repositorio

utilizo la práctica controlador delgada con cada vista de tener un modelo vista única que se devuelve del servicio relevante.

Ejemplo rápida: Vista:/NewAppointment/Paso 1

Su controler se vería así:

public ActionResult Step1() 
{ 
    return View(_appointmentService.Step1GetModel()); 
} 

y la capa de servicio de cita se vería así:

public Step1Model Step1GetModel() 
{ 
    return new Step1Model(); 
} 

Así

Tengo varias capas de servicio diferentes en uso a través de mi aplicación, cada una implementando una interfaz distinta.

Mi pregunta aparece cuando necesito que una capa de servicio interactúe con otra capa de servicio. En este caso, ¿es una mejor práctica pasar una referencia de interfaz a la llamada de servicio, o debería dejar que el controlador maneje la recopilación de todos los datos y luego volver a pasar los resultados relevantes al servicio?

Ejemplo:

decir que quiero llenar mi vista del modelo con la información del cliente por defecto. Las dos formas que veo de hacer esto son:

pasa una referencia de interfaz de cliente para el servicio de cita, y luego dejar que la llamada de servicio cita el método GetCustomer apropiado en el servicio al cliente ...

En Código:

private ICustomerService _customerService; 
private IAppointmentService _appointmentService; 

public ActionResult Step1() 
{ 
    var viewModel = _appointmentService.Step1GetModel(_customerService); 
    return View(viewModel); 
} 

O

Deje que el controlador de manejar la lógica de conseguir que el cliente, a continuación, pasar a ese resultado con el servicio de cita.

En Código:

private ICustomerService _customerService; 
private IAppointmentService _appointmentService; 

public ActionResult Step1() 
{ 
    var customer = _customerService.GetCustomer(); 
    var viewModel = _appointmentService.Step1GetModel(customer); 
    return View(viewModel); 
} 

Estoy dividida en cuanto a que sería mejor práctica. El primero mantiene el controlador delgado y fino, pero crea una dependencia entre servicios entre el servicio de citas y el servicio al cliente. El segundo pone más lógica en el controlador, pero mantiene los servicios totalmente independientes.

¿Alguien tiene ideas sobre cuál sería una mejor práctica?

Gracias ~

Answer 1

Pensando en su puramente conceptual no creo que tenga sentido para su services saber nada acerca de su view models. Una de las principales razones para tener un controlador en primer lugar es separar la lógica de la vista de la lógica de su negocio, pero si sus servicios devuelven datos específicos de la vista, entonces están inherentemente vinculados a su lógica comercial.

Lo ideal sería esperar que el método para tener este aspecto:

public ActionResult Step1() 
{ 
    var customer = _customerService.GetCustomer(); 
    var appointment = _appointmentService.GetAppointmentFor(customer); 

    var viewModel = new Step1ViewModel(customer, appointment); 

    return View(viewModel); 
} 

Para responder a su pregunta más directamente sin embargo, yo creo que está bien para sus servicios para saber el uno del otro, son parte de la misma capa conceptualmente.

Además, una cosa más ...

Parece que usted tiene una gran cantidad de jerarquías de clases paralelas con lo que tienen servicios, repositorios y controladores. Podría tener más sentido utilizar algo así como la unidad de patrón de trabajo y un potente ORM para hacer algo como:

public MyController(IUnitOfWork unitOfWork)... 

public ActionResult Step1() 
{ 
    var customer = unitOfWork.Find<Customer>(); 
    var viewModel = new Step1ViewModel(customer.Appointment); 
    return View(viewModel); 
} 

Después de todo, el valor de su aplicación es en el modelo, no en los servicios.