业务全放在controller

将业务全部放在controller是不好的做法。这样会导致controller的代码变得臃肿，难以维护和扩展。更好的做法是将业务逻辑放在service层，controller层只负责接收请求和返回响应。这样可以实现代码的解耦和复用。同时，可以通过引入其他的组件，如DTO、VO、BO等，更好地管理数据模型。

相关问题

trycatch一般放在controller层还是service层

在编写代码时，try-catch块通常应该放在service层，而不是在controller层。原因如下：

1. 保持controller层的简单性：controller层应该处理HTTP请求，并直接调用service层来执行业务逻辑。如果我们将try-catch块放在controller层中，那么它们将占据一部分controller代码，使其变得更繁琐复杂。而把try-catch块放在service层中，可以隐藏这些错误处理细节，并使得controller层代码更加简单。

2. 提高代码复用性：将try-catch块放在service层中能够提高代码的复用性。一般来说，我们会针对每种异常都编写对应的错误处理逻辑，但这些逻辑在不同的controller中可能重复出现。通过将try-catch块放在service层中，我们可以避免这种情况，将错误处理逻辑集中在一起进行管理和复用。

3. 方便进行单元测试：如果我们将try-catch块放在controller层中，就需要模拟各种异常情况，以确保控制器在不同异常情况下的行为正确。如果我们将try-catch块放在service层中，它们就可以更容易地进行单元测试，因为我们只需要模拟底层服务的行为即可。

总之，将try-catch块放在service层中是一个更好的实践，原因是它可以保持控制器简单、提高代码复用性，并方便进行单元测试。

controller调用controller

在MVC架构中，一个controller可以调用另一个controller，但这种做法并不被推荐。因为controller的主要职责是处理用户请求和控制业务逻辑，如果一个controller需要调用另一个controller，那么就意味着这个controller的职责已经超出了范围，需要重新设计。通常情况下，应该将共同的业务逻辑抽象出来，放在一个service或者helper类中，然后在需要的controller中调用。这样可以避免代码的重复和混乱，也更符合MVC架构的设计原则。