写JAVA后端代码时逻辑混乱怎么办？

后端代码复杂度通过分拆、分而治之来解决。首先通常通过拆分工程、多个工程间可以存在依赖关系，但一定要单向依赖，不能成环，如果有环就得考虑把环形依赖部分拆分出来成为单独的工程，来解决环形依赖。

对于工程里的代码可通过横向拆分、纵向分拆来降低复杂度。横向分层按controler、service、dao、sqlmap，纵向分模块system、biz1、biz2……bizN，但在数通畅联内部，横、纵向拆分相结合模式，如下图：

首先通过横向分拆出controller、cxmodule、module等层次，module作为业务层根据业务功能的不同进行纵向分拆，分成analysis、dwmodel、metadata、schedule等功能模块，在各个功能模块中，横向分拆出exteral、handler、service、sqlmap，其中exteral负责数据接口，提供可调用的服务和接口；handler作为控制层，通过调度代码负责业务的调度，以及一些参数封装、结果集处理等操作；service则是负责具体业务的业务处理层，除了增删改查外，一些贴近业务的功能也会在service中完成；sqlmap用于定义操作数据库的SQL语句。

通过这种分层的方式，实现代码层次的分隔，做到各守各层、结构清晰，对于一些跨模块调用的接口，如在不同模块中需要对同一张数据表进行操作时，可以将接口提升到上层cxmodule中作为公共接口，实现类和方法的复用；对于一些可复用的、相对独立的功能，可以通过在cxmodule中定义一个干净的接口，在module的功能模块中通过实现接口实现业务逻辑，而不使用spring的事务管理机制，降低代码的复杂度。

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

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

Mvc就是所谓的model模型，view视图，controller控制器。

每个层都有明确分工。

简单的项目抛开nignx，网关，一般都是前端发一个请求到后端，首先到达contoller然后是service层再然后是dao层。

这里的service层就是所谓的业务层，专门负责业务处理操作，而dao层负责和数据库打交道，从db拿数据返给service，sevice处理完返给controller层，controller通过视图解析器，解析完通过浏览器渲染页面。

说到这里基本上，我想答案已经很明显了。那就是Java业务逻辑写在service层。

而sevice层其实又涉及到接口和接口实现。

就是我们一般写代码都会定义一个接口供controller去调用。

其实service接口的实现类最终才应该是写业务逻辑的地方。

当然很多公司可能不止一个sevice层，比如还有一个manager层继续对数据做特殊业务处理，这里只是简单的说下大致情况。

每个公司每个项目根据自身业务，架构可能不太一样。但本质是一样的。

总结一下就是业务逻辑肯定需要单独作为一层去处理，这样既方便拓展，也方便维护。切记不要把所有的业务逻辑都写在controller里面。

每个层都有自己的分工，都揉在一块不仅仅代码冗长看起来还很乱，不清晰。

好了，希望我的回答能帮到你！

感兴趣可以关注，共同学习交流！

Java开发写业务逻辑代码难不难，是自己创造还是根据文档说明书？

谢谢邀请！

写业务逻辑代码通常是Java程序员的主要工作内容，大部分业务逻辑代码并没有太大的难度，只要按照业务规则编写就可以了。

Java代码编写有多个角色参与，不同的角色有不同的任务划分，通常情况下在项目功能设计结束之后，架构师就会开始进行架构设计和顶层的接口设计，具体会包括项目的结构划分，技术选型等具体内容。

大部分软件开发项目都分成两个大的组成部分，一部分是“容器开发”，容器开发是整个系统开发的核心，主要的基础性功能都封装在容器当中，另一部分是“应用开发”，应用开发就是根据业务逻辑规则进行具体的功能编写，通常需要调用容器提供的基础性功能接口来完成。从这个角度来看，业务逻辑代码的编写属于应用型开发，所以并不会有太大的难度。

通常情况下，做容器开发的程序员往往就是所谓的“研发级程序员”，容器开发涉及到的内容包括系统级功能、资源管理、并发管理、角色管理等内容，开发内容包括大量的算法设计和实现，同时还要考虑到系统的稳定性和性能，这部分开发内容需要丰富的经验，同时需要程序员具备一定的研发能力和研究方法。

做应用级开发的程序员往往都是调用容器提供的功能进行具体的功能组织，大部分程序员都是从应用级开发开始做起的，这部分程序员的工作虽然难度不大，但是内容却比较多，因为大量的业务逻辑都需要应用级程序员完成，所以工作压力还是比较大的。

当前，随着软件开发流程逐渐规范化，所以大部分应用级程序员都会有对应的开发任务文档，每天的任务都比较清晰，只要按照任务文档进行开发和提交就可以了。

我从事互联网行业多年，目前也在带计算机专业的研究生，主要的研究方向集中在大数据和人工智能领域，我会陆续在头条写一些关于互联网技术方面的文章，感兴趣的朋友可以关注我，相信一定会有所收获。

如果有互联网方面的问题，也可以咨询我，谢谢！

java程序员，公司框架太智能会不会削弱编程能力？

你这个问题问的，那大公司里的人都不行吗？

大公司里很多的框架，很多的平台化，很多的自动化的流程，高度的智能化框架。

相反的，

公司框架太智能反而会强化你的编程能力

首先明白什么是框架

你的问题可以这么理解， Java是一种编程语言，随它产生的框架是一种特定的编码模式（包括很多的工具和lib）。

假如，每当你从头开始构建一个项目时，你都不用框架，很多的基础工作你都要做，包括打印，调试，连接数据库，编译等等，那么你还有多少时间来进行你的业务开发？但随着应用程序越来越大，记住你写的东西变得很多很难，调试代码变得更加困难。
为了避免这样的问题，框架才被广泛使用。

你有本事，每次一个项目都写一个自己的连接数据库类来试试。

使用框架

使用框架能让你更注重你的特长，专注于你要做的工作。（不管是业务的还是非业务的工作）。

你不需要花费通常需要几个小时和几百行甚至更多的代码才能完成的基本任务。

要学会站在巨人的肩膀上，而不是从0开始研究为什么1 1=2 。

欢迎关注，解锁更多，共同进步！

Java Web开发中，业务逻辑写在SQL里好还是代码里好呢？有什么建议吗？

目前大部分研发团队都要求业务逻辑用代码来实现，SQL操作往往都是基本操作。用SQL来表现业务逻辑，也就是通过存储过程的方式来表现业务逻辑是比较传统的开发方案。

在C/S时代很多逻辑的实现都是通过SQL来实现的，主要原因是业务规模和部署方式决定的。早期的C/S编程时代往往都是非分布式环境下的开发，而且大多数情况下并不需要考虑移植性问题，此时采用SQL来完成业务逻辑是比较方便的处理方式。

采用存储过程来完成业务逻辑最大的好处是性能会比较好，但是这也取决于业务规模的大小，如果业务规模过大，那么性能会下降的比较厉害。而早期的数据存储规模比较小，所以采用存储过程的方式是比较方便的。

目前的Web开发已经到了大数据时代、云计算时代，业务类型和业务规模都有了较大的变化，尤其是大数据时代下NoSql数据库的广泛采用，使用SQL语句来完成业务逻辑的情景就更少了。而且，目前的程序大部分都是分布式方式，采用Sql存储过程的方式来处理业务逻辑会非常麻烦，而且会导致整个项目的移植性和可读性都严重下降。

目前在传统企业的开发团队中采用Sql来处理业务逻辑的情况比较常见，因为大部分传统企业的数据库还依然是关系型数据库，而且不存在移植性要求，这种固定场景下的开发是完全可以使用Sql来处理业务逻辑的。未来使用Sql处理业务逻辑的情况也有一定的应用场景，所以学习存储过程的编写还是有一定必要的。

我的研究方向是大数据和人工智能，目前也在带大数据方向的研究生，我会陆续在头条上写一些关于大数据方面的文章，感兴趣的朋友可以关注我的头条号，相信一定会有所收获。

如果有大数据方面的问题，也可以咨询我。

谢谢！

java编程题 java设计一个点名程序 java实现随机点名

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