java Service层和Dao层真的有必要每个类都加上接口吗？
Service层和Dao层真的有必要每个类都加上接口吗？
这主要取决于您的项目：
例如，如果项目中使用了hibernate，以后可能会切换到mybatis，那么Dao需要使用这个接口。这不会影响上层代码的更改。
另一个例子是，项目是一个单一的应用程序。任何代码修改都需要重新编译整个项目，因此不需要接口。如果项目是由模块编译和部署的，那么可以使用接口解耦。假设修改了Dao，只需要重新编译和部署Dao模块，而不影响上层模块。
此外，如果项目团队中有许多新手，简单的代码结构可能更合适。复杂项目结构的学习成本较高。
如果工程进度非常紧迫，我们可以用简单粗暴的方式用经济成本来说明原因。
使用接口的成本是不使用接口的成本（包括后续维护成本）。
如果项目变化很大，部署了模块，项目不急，使用接口的成本比不使用接口的成本低，虽然早期不使用接口似乎更简单；相反，不使用接口的成本低，而且连框架都不能用～
毕竟工具是提高效率的，那你为什么不能和自己相处呢
java业务逻辑，写在哪里比较好？
现在很多公司的开发人员都应该采用MVC架构。
MVC是所谓的模型、视图、控制器。
每一层都有明确的分工。
对于简单的项目，不管nignx如何，网关通常都会将请求从前端发送到后端，首先发送到控制器，然后发送到服务层，然后发送到Dao层。
这里的服务层就是所谓的业务层，专门负责业务处理操作，而Dao层则负责处理数据库，将数据库中的数据带回服务，经过服务处理后返回控制器层。控制器通过视图解析器解析页面，并通过浏览器呈现页面。
基本上，我认为答案是显而易见的。也就是说，Java业务逻辑是在服务层编写的。
事实上，服务层涉及接口和接口实现。
在编写代码时，我们通常为控制器定义一个调用接口。
实际上，服务接口的实现类应该是编写业务逻辑的地方。
当然，许多公司可能有多个服务层，例如，有一个管理层继续对数据进行特殊的业务处理。这里只是一个简单的概述。
每个公司的每个项目根据其自身业务可能有不同的体系结构。但本质是一样的。
综上所述，业务逻辑必须作为一个独立的层来处理，这样便于扩展和维护。记住不要在控制器中编写所有业务逻辑。
每一层都有自己的分工，是捏合在一起的。代码不仅冗长，而且杂乱无章。
好吧，我希望我的回答能帮助你
！如果你有兴趣，可以关注一下，一起学习交流
java调用其他模块，是放在control层通过service接口调用好，还是放在service层通过dao的接口调用好？
我建议调用其他模块的接口，并通过服务层调用它们。如果模块a的服务调用模块B的Dao，那么模块B的Dao与模块a是耦合的，假设随着业务的发展，模块a和模块B需要作为服务分开发布，那么模块a和模块B需要维护模块B的Dao，模块a和模块B的开发人员需要熟悉模块B的Dao，在模块B的表中添加或删除字段后，需要同时通知模块a和模块B的开发人员，这显然不容易维护。另外，将B的Dao模块引入到a模块和B模块中，即a模块可以直接访问B模块Dao的所有功能，Dao模块通常是一些基本操作。相反，服务层通常具有特定的业务含义。通过服务公开具有特定含义的业务接口，我们可以避免将所有底层操作公开给外部模块。假设随着业务的进一步发展，模块a和模块B需要分支数据库，模块a和模块B分别使用各自的数据库。那么当a引入B的Dao时，必须访问B的数据库，这意味着a需要访问a、B模块的数据库，如果有C、D模块，那么a需要访问a、B、C、D多个模块的数据库，这显然不利于开发和维护，同时也不利于被引用模块的数据安全。
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
