Question

我一直在阅读如何通过将业务逻辑移动到服务层来使我的控制器干净简单。我遇到的问题是，如果我：

将服务层与模型对齐，例如UserService，AuthenticationService，然后减少冗余，但它也假定UserService的每个方法，例如update（）将以相同的方式使用，但我们所知的业务逻辑在应用程序的不同部分是不同的。服务于多个场景的方法通常很脏，因为如果应用程序的3个不同部分使用相同的方法，那么您必须满足所有3个部分。
对齐服务图层以反映控制器及其方法。这种方式有可能增加冗余，但它也使得你不会构建单一的金子弹方法，这些方法应该涵盖他们所需要的任何场景。

我在下面展示了两个例子：

反映模特

class UserController extends Controller {
     public function update(Request $request){

          // Load user service and create history

          $user_service = new UserService();
          $user_service->update($request);

          // Load user history service and create history

          $user_history_service = new UserHistoryService();
          $user_history_service->createHistory($request);

          // json response with success

          return response()->json([]);

     }
}

反映控制器

class UserController extends Controller {
     public function update(Request $request){

          // Load user controller service, update user and create history
          $service = new UserControllerService();
          $service->updateUser($request);
          $service->createHistory($request);

          // return json response with success

          return response()->json([]);

     }
}

我发现的两种方式正是我从阅读中收集到的，也是我自己的一些想法。哪种方式适当缩放，我猜是最少的牺牲？

MVC Web应用程序的服务层应该是什么样的？

0 个答案: