java持久层框架 java业务逻辑，写在哪里比较好？

java业务逻辑，写在哪里比较好？

现在很多公司的开发人员都应该采用MVC架构。

MVC是所谓的模型、视图、控制器。

每一层都有明确的分工。

对于简单的项目，不管nignx如何，网关通常都会将请求从前端发送到后端，首先发送到控制器，然后发送到服务层，然后发送到Dao层。

这里的服务层就是所谓的业务层，专门负责业务处理操作，而Dao层则负责处理数据库，将数据库中的数据带回服务，经过服务处理后返回控制器层。控制器通过视图解析器解析页面，并通过浏览器呈现页面。

基本上，我认为答案是显而易见的。也就是说，Java业务逻辑是在服务层编写的。

事实上，服务层涉及接口和接口实现。

在编写代码时，我们通常为控制器定义一个调用接口。

实际上，服务接口的实现类应该是编写业务逻辑的地方。

当然，许多公司可能有多个服务层，例如，有一个管理层继续对数据进行特殊的业务处理。这里只是一个简单的概述。

每个公司的每个项目根据其自身业务可能有不同的体系结构。但本质是一样的。

综上所述，业务逻辑必须作为一个独立的层来处理，这样便于扩展和维护。记住不要在控制器中编写所有业务逻辑。

每一层都有自己的分工，是捏合在一起的。代码不仅冗长，而且杂乱无章。

好吧，我希望我的回答能帮助你

！如果你有兴趣，可以关注一下，一起学习交流

请问JAVA三层架构、持久层、业务层、表现层都该怎么理解？和MVC三层模型有什么区别？

持久层用于固化数据，例如Dao层，它操作数据库来存储数据。业务层用来实现整个业务逻辑。例如，前台获取数据，逻辑层解析数据，验证数据，等等。操作表示层很好地解释了您现在看到的一些网页属于表示层。在XX系统中可以使用一些HTML、JSP、swing来实现MV，前台页面属于视图，一组运行在前台和后台持久层的模型是model（由EJB、spring实现），而控制器（由struts实现）连接前台和后台进行逻辑操作

标准的javaee开发基于三层架构，即表示层、业务层、持久层（我习惯使用数据访问层）。持久层框架是操作数据库的框架。通常，编写操作数据库的代码是使用JDBC直接访问。持久层框架封装了JDBC代码，这使得Java程序员更容易编写。

除了mybatis，持久层框架中还有hibernate和EJB。目前，mybatis和Hibernate在项目开发中被广泛使用

struts 2和spring mvcstructs在表示层框架中使用较少，struts 2代替了struts

spring在业务层框架中使用较多

目前struts 2在spring Hibernate（又称SSH）的开发中使用较多

另一个是spring MVC mybatis spring，现在很多人都在用它

这主要取决于你的项目：

例如，如果项目中原来使用的hibernate以后需要切换到mybatis，Dao就需要使用这个接口。这不会影响上层代码的更改。

另一个例子是，项目是一个单一的应用程序。任何代码修改都需要重新编译整个项目，因此不需要接口。如果项目是由模块编译和部署的，那么可以使用接口解耦。假设修改了Dao，只需要重新编译和部署Dao模块，而不影响上层模块。

此外，如果项目团队中有许多新手，简单的代码结构可能更合适。复杂项目结构的学习成本较高。

如果工程进度非常紧迫，我们可以用简单粗暴的方式用经济成本来说明原因。

使用接口的成本是不使用接口的成本（包括后续维护成本）。

如果项目变化很大，部署了模块，项目不急，使用接口的成本比不使用接口的成本低，虽然早期不使用接口似乎更简单；相反，不使用接口的成本低，而且连框架都不能用～

毕竟工具是提高效率的，那你为什么不能和自己相处呢！

java持久层框架 dao层只在java中使用吗 java持久层框架有哪些

版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。