Question

我有一个C＃MVC应用程序，我按以下方式分解：查看 - ＆gt;控制器 - ＆gt;服务 - ＆gt;存储库

我使用瘦控制器练习，每个视图都有一个从相关服务返回的唯一视图模型。

快速示例：查看：/ NewAppointment / Step1

它的控制器看起来像这样：

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

约会服务层看起来像这样：

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

因此，我在整个应用程序中使用了几个不同的服务层，每个服务层都实现了一个独特的界面。

当我需要让一个服务层与另一个服务层交互时，我的问题就出现了。在这种情况下，更好的做法是将接口引用传递给服务调用，还是应该让控制器处理收集所有数据然后将相关结果传递回服务？

示例：

假设我想默认使用客户的信息填充我的视图模型。我这样做的两种方式是：

将客户界面引用传递给约会服务，然后让约会服务在客户服务中调用相应的GetCustomer方法...

在代码中：

 private ICustomerService _customerService;
 private IAppointmentService _appointmentService;

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

OR

让控制器处理获取客户的逻辑，然后将结果传递给约会服务。

在代码中：

private ICustomerService _customerService;
private IAppointmentService _appointmentService;

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

我被撕成了哪个更好的做法。第一种方法使控制器保持良好和精简，但在约会服务和客户服务之间创建了服务间依赖关系。第二个将更多逻辑放入控制器，但保持服务完全独立。

任何人都有关于哪种更好的做法的想法？

感谢〜

Answer 1

从纯粹的概念上思考我认为services对你的view models一无所知是不合理的。首先拥有控制器的主要原因之一是将您的视图逻辑与业务逻辑分开，但如果您的服务返回特定于视图的数据，则它们本身就与您的业务逻辑相关联。

理想情况下，我希望该方法看起来像这样：

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

    var viewModel = new Step1ViewModel(customer, appointment);

    return View(viewModel);
}

为了更直接地回答你的问题，我认为你的服务很好地了解对方，他们是同一个概念层的一部分。

另外还有一件事......

听起来你有很多并行类层次结构，有服务，存储库和控制器。使用像工作单元模式和强大的ORM这样的东西可能更有意义：

public MyController(IUnitOfWork unitOfWork)...

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

毕竟，您的应用程序的价值在模型中，而不在服务中。

是否将服务引用传递给另一个服务层的不良做法？

1 个答案: