4

我正在按照 MVC 模式在春季开发一个 Web 应用程序，并且想知道什么被认为是制作可靠服务层的“最佳实践”。这个问题的原因是以下示例情况：

加载了用于编辑用户信息的页面。提交此表单后，我在特定的 Command 类中的控制器方法中收集其所有数据，该类仅包含后续操作（更新用户）所需的数据。

我现在可以想到几种情况来将此信息传递给我的服务层：

  • 传递命令本身：userService.save(command);
  • 传递模型类，在控制器中获取：userService.save(user);
  • 同时传递模型类和命令： userService.save(user, command);
  • 单独传递所有参数：userService.save(command.getName(), ...)

在我看来，传递命令类本身看起来是最优雅的解决方案，因为我可以首先使用框架自动验证所有值，然后将它们传递给我的服务。我在这里担心的是，当我从另一个类（而不是通过我的表单/控制器）调用该方法时，我可以用无效数据填充这个命令对象，从而导致服务层中可能出现错误。

你会推荐什么，为什么？

4

4 回答 4

1

看到你的我有以下想法传递命令本身： userService.save(command);

这可能不是一个好主意，因为您的 Service 层不必要地依赖于 Command 对象

Passing a model class, fetched in the controller: userService.save(user);

我会为此投票。服务层只有它真正应该知道的

Passing both a model class and the command: userService.save(user, command);

否。与第一个选项相同

Passing all of the parameters individually: userService.save(command.getName(), ...)

嗯……不确定……将来可能是维护开销。

I think if you want to do the validation, Use validation util classes to do the validation 
    which can be used for both Service and UI layer. Here a lot validation can be centralized.
于 2013-02-08T11:30:45.867 回答
0

使用您的 Command 对象的任何选项都会引起麻烦。它打破了松散耦合。现在您的服务层与服务层紧密耦合。请不要这样做。

（编辑：在下面的回答中，当我说表示层的模型时，我指的是视图模型，而服务层是域模型）发送模型对象看起来是一个不错的选择。但是，这取决于模型是如何创建的。有时，表示层需要不同的模型结构，而服务层需要适度/完全不同的结构。

如果两个层有不同的需求，那么您需要创建 2 个模型结构。这样，当表示层发生变化时，服务层的模型结构就不必改变。这很重要，因为服务可能有多个消费者，并且可能无法在表示层更改时更改。

如果它们没有不同的结构，我仍然会从服务层的角度创建它们，因为服务是这里真正的可重用组件。

于 2013-02-08T21:35:53.670 回答
0

在他的 MVC 书中，Dino Esposito 建议创建一个接受和返回视图模型的“工人”类。控制器使用视图模型调用工作人员，然后工作人员根据需要进行委托。我没有在实践中使用它，但理论上它似乎是一个不错的解决方案。

于 2013-02-07T12:30:32.433 回答
0

在多层系统中处理命令时要遵循的一个很好的模式是拥有一个 CommandBus 服务，该服务将您的命令路由到它们的特定处理程序。这样，您就可以将控制器与服务分离（同时将其与通用路由系统耦合）。

commandBus.handle(command);

您必须在配置命令总线处理程序时做额外的工作，但从长远来看，当您能够重用该路由信息时，它会有所回报：

commandBus.register(commandType, handlerService);

然后您可以移动commandBus服务中命令的验证（即使这将意味着对 commandBus 的一些关注）

commandBus.registerValidator(commandType, validatorsCollection);

于 2013-02-08T22:00:11.767 回答