Question

（但据我所知，它是调解器黑白控制器和DAO层。）或者我们可以直接在控制器中使用dao依赖，这是一个好习惯！ ???如下所示

@Controller
public class HomeController {   

    // @Autowired
    // private UserServiceImpl userService;
    @Autowired
     private UserDAOImpl userDAOService;

   @RequestMapping(value = "login", method = RequestMethod.GET)
public String login(..){
   // String res = userService.someOperation();
      String res = userDAOService.someOperation(); 
      ............
         }
   }

Answer 1

我们需要服务层的一个很好的理由是松散耦合：

假设您的控制器类中有100个api，并且有20个dao方法为它们提供服务。

现在，如果您直接在控制器中调用dao方法，并且稍后您希望为这些控制器提供不同的dao方法。

您必须更换所有100个控制器吗？

所以如果有20个服务方法调用那些20个dao方法。

现在，如果您想要更改为这100个控制器提供服务的dao方法，您只需更改服务方法（即20种方法）以指向新的doa方法，而不是更改100个控制器类。

这是如何实现松耦合的，是一种更好的编程方式。希望这可以帮助你：）

Answer 2

通常将DAO直接放入控制器是一个坏主意，除非Controller非常简单（如一种少于10行的方法 - 可能是单元测试）。这并不一定意味着您绝对必须将服务拆分为单独的可部署。对于许多较小的项目，“服务”是直接与应用程序的其余部分打包的接口。

服务层将提供帮助的地方是您拥有更大的应用程序，尤其是当这些服务执行不同的角色时。例如，如果您的业务处于制造状态且您的库存服务收到大量流量，您可以将其拆分为可自行部署的服务，并将您的用户管理和营销部署到单独的可部署中。像这样拆分服务的优点是您可以独立扩展繁忙的服务。例如，如果您在AWS上运行，则更有意义的是自己扩展库存服务，而不是仅仅因为一个部件一直被调用而扩展整个应用程序。

Answer 3

一般来说，混合是一个糟糕的实践，控制器和道或控制器和服务。

使用DAO的主要原因是从业务操作/逻辑中分离数据库功能。在项目中使用DAO和服务也可以实现松散耦合，即（彼此之间的依赖性较小）

就商业逻辑而言，这是从ATM取款的一个例子

首先插入自动提款卡。
然后输入您的金额。
然后输入您的个人识别码。
然后最终处理您的交易。

此流程是您的业务逻辑。

spring mvc中服务层的需求是什么？推荐什么样的逻辑？

3 个答案: