寫JAVA后端代碼時邏輯混亂怎么辦？后端代碼復(fù)雜度通過分拆、分而治之來解決。首先通常通過拆分工程、多個工程間可以存在依賴關(guān)系，但一定要單向依賴，不能成環(huán)，如果有環(huán)就得考慮把環(huán)形依賴部分拆分出來成為單獨

寫JAVA后端代碼時邏輯混亂怎么辦？

后端代碼復(fù)雜度通過分拆、分而治之來解決。首先通常通過拆分工程、多個工程間可以存在依賴關(guān)系，但一定要單向依賴，不能成環(huán)，如果有環(huán)就得考慮把環(huán)形依賴部分拆分出來成為單獨的工程，來解決環(huán)形依賴。

對于工程里的代碼可通過橫向拆分、縱向分拆來降低復(fù)雜度。橫向分層按controler、service、dao、sqlmap，縱向分模塊system、biz1、biz2……bizN，但在數(shù)通暢聯(lián)內(nèi)部，橫、縱向拆分相結(jié)合模式，如下圖：

首先通過橫向分拆出controller、cxmodule、module等層次，module作為業(yè)務(wù)層根據(jù)業(yè)務(wù)功能的不同進行縱向分拆，分成analysis、dwmodel、metadata、schedule等功能模塊，在各個功能模塊中，橫向分拆出exteral、handler、service、sqlmap，其中exteral負責(zé)數(shù)據(jù)接口，提供可調(diào)用的服務(wù)和接口；handler作為控制層，通過調(diào)度代碼負責(zé)業(yè)務(wù)的調(diào)度，以及一些參數(shù)封裝、結(jié)果集處理等操作；service則是負責(zé)具體業(yè)務(wù)的業(yè)務(wù)處理層，除了增刪改查外，一些貼近業(yè)務(wù)的功能也會在service中完成；sqlmap用于定義操作數(shù)據(jù)庫的SQL語句。

通過這種分層的方式，實現(xiàn)代碼層次的分隔，做到各守各層、結(jié)構(gòu)清晰，對于一些跨模塊調(diào)用的接口，如在不同模塊中需要對同一張數(shù)據(jù)表進行操作時，可以將接口提升到上層cxmodule中作為公共接口，實現(xiàn)類和方法的復(fù)用；對于一些可復(fù)用的、相對獨立的功能，可以通過在cxmodule中定義一個干凈的接口，在module的功能模塊中通過實現(xiàn)接口實現(xiàn)業(yè)務(wù)邏輯，而不使用spring的事務(wù)管理機制，降低代碼的復(fù)雜度。

java業(yè)務(wù)邏輯，寫在哪里比較好？

現(xiàn)在很多公司開發(fā)人員應(yīng)該采用都是mvc架構(gòu)。

Mvc就是所謂的model模型，view視圖，controller控制器。

每個層都有明確分工。

簡單的項目拋開nignx，網(wǎng)關(guān)，一般都是前端發(fā)一個請求到后端，首先到達contoller然后是service層再然后是dao層。

這里的service層就是所謂的業(yè)務(wù)層，專門負責(zé)業(yè)務(wù)處理操作，而dao層負責(zé)和數(shù)據(jù)庫打交道，從db拿數(shù)據(jù)返給service，sevice處理完返給controller層，controller通過視圖解析器，解析完通過瀏覽器渲染頁面。

說到這里基本上，我想答案已經(jīng)很明顯了。那就是Java業(yè)務(wù)邏輯寫在service層。

而sevice層其實又涉及到接口和接口實現(xiàn)。

就是我們一般寫代碼都會定義一個接口供controller去調(diào)用。

其實service接口的實現(xiàn)類最終才應(yīng)該是寫業(yè)務(wù)邏輯的地方。

當(dāng)然很多公司可能不止一個sevice層，比如還有一個manager層繼續(xù)對數(shù)據(jù)做特殊業(yè)務(wù)處理，這里只是簡單的說下大致情況。

每個公司每個項目根據(jù)自身業(yè)務(wù)，架構(gòu)可能不太一樣。但本質(zhì)是一樣的。

總結(jié)一下就是業(yè)務(wù)邏輯肯定需要單獨作為一層去處理，這樣既方便拓展，也方便維護。切記不要把所有的業(yè)務(wù)邏輯都寫在controller里面。

每個層都有自己的分工，都揉在一塊不僅僅代碼冗長看起來還很亂，不清晰。

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

感興趣可以關(guān)注，共同學(xué)習(xí)交流！

Java開發(fā)寫業(yè)務(wù)邏輯代碼難不難，是自己創(chuàng)造還是根據(jù)文檔說明書？

謝謝邀請！

寫業(yè)務(wù)邏輯代碼通常是Java程序員的主要工作內(nèi)容，大部分業(yè)務(wù)邏輯代碼并沒有太大的難度，只要按照業(yè)務(wù)規(guī)則編寫就可以了。

Java代碼編寫有多個角色參與，不同的角色有不同的任務(wù)劃分，通常情況下在項目功能設(shè)計結(jié)束之后，架構(gòu)師就會開始進行架構(gòu)設(shè)計和頂層的接口設(shè)計，具體會包括項目的結(jié)構(gòu)劃分，技術(shù)選型等具體內(nèi)容。

大部分軟件開發(fā)項目都分成兩個大的組成部分，一部分是“容器開發(fā)”，容器開發(fā)是整個系統(tǒng)開發(fā)的核心，主要的基礎(chǔ)性功能都封裝在容器當(dāng)中，另一部分是“應(yīng)用開發(fā)”，應(yīng)用開發(fā)就是根據(jù)業(yè)務(wù)邏輯規(guī)則進行具體的功能編寫，通常需要調(diào)用容器提供的基礎(chǔ)性功能接口來完成。從這個角度來看，業(yè)務(wù)邏輯代碼的編寫屬于應(yīng)用型開發(fā)，所以并不會有太大的難度。

通常情況下，做容器開發(fā)的程序員往往就是所謂的“研發(fā)級程序員”，容器開發(fā)涉及到的內(nèi)容包括系統(tǒng)級功能、資源管理、并發(fā)管理、角色管理等內(nèi)容，開發(fā)內(nèi)容包括大量的算法設(shè)計和實現(xiàn)，同時還要考慮到系統(tǒng)的穩(wěn)定性和性能，這部分開發(fā)內(nèi)容需要豐富的經(jīng)驗，同時需要程序員具備一定的研發(fā)能力和研究方法。

做應(yīng)用級開發(fā)的程序員往往都是調(diào)用容器提供的功能進行具體的功能組織，大部分程序員都是從應(yīng)用級開發(fā)開始做起的，這部分程序員的工作雖然難度不大，但是內(nèi)容卻比較多，因為大量的業(yè)務(wù)邏輯都需要應(yīng)用級程序員完成，所以工作壓力還是比較大的。

當(dāng)前，隨著軟件開發(fā)流程逐漸規(guī)范化，所以大部分應(yīng)用級程序員都會有對應(yīng)的開發(fā)任務(wù)文檔，每天的任務(wù)都比較清晰，只要按照任務(wù)文檔進行開發(fā)和提交就可以了。

我從事互聯(lián)網(wǎng)行業(yè)多年，目前也在帶計算機專業(yè)的研究生，主要的研究方向集中在大數(shù)據(jù)和人工智能領(lǐng)域，我會陸續(xù)在頭條寫一些關(guān)于互聯(lián)網(wǎng)技術(shù)方面的文章，感興趣的朋友可以關(guān)注我，相信一定會有所收獲。

如果有互聯(lián)網(wǎng)方面的問題，也可以咨詢我，謝謝！

java程序員，公司框架太智能會不會削弱編程能力？

你這個問題問的，那大公司里的人都不行嗎？

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

相反的，

公司框架太智能反而會強化你的編程能力

首先明白什么是框架

你的問題可以這么理解， Java是一種編程語言，隨它產(chǎn)生的框架是一種特定的編碼模式（包括很多的工具和lib）。

假如，每當(dāng)你從頭開始構(gòu)建一個項目時，你都不用框架，很多的基礎(chǔ)工作你都要做，包括打印，調(diào)試，連接數(shù)據(jù)庫，編譯等等，那么你還有多少時間來進行你的業(yè)務(wù)開發(fā)？但隨著應(yīng)用程序越來越大，記住你寫的東西變得很多很難，調(diào)試代碼變得更加困難。
為了避免這樣的問題，框架才被廣泛使用。

你有本事，每次一個項目都寫一個自己的連接數(shù)據(jù)庫類來試試。

使用框架

使用框架能讓你更注重你的特長，專注于你要做的工作。（不管是業(yè)務(wù)的還是非業(yè)務(wù)的工作）。

你不需要花費通常需要幾個小時和幾百行甚至更多的代碼才能完成的基本任務(wù)。

要學(xué)會站在巨人的肩膀上，而不是從0開始研究為什么1 1=2 。

歡迎關(guān)注，解鎖更多，共同進步！

Java Web開發(fā)中，業(yè)務(wù)邏輯寫在SQL里好還是代碼里好呢？有什么建議嗎？

目前大部分研發(fā)團隊都要求業(yè)務(wù)邏輯用代碼來實現(xiàn)，SQL操作往往都是基本操作。用SQL來表現(xiàn)業(yè)務(wù)邏輯，也就是通過存儲過程的方式來表現(xiàn)業(yè)務(wù)邏輯是比較傳統(tǒng)的開發(fā)方案。

在C/S時代很多邏輯的實現(xiàn)都是通過SQL來實現(xiàn)的，主要原因是業(yè)務(wù)規(guī)模和部署方式?jīng)Q定的。早期的C/S編程時代往往都是非分布式環(huán)境下的開發(fā)，而且大多數(shù)情況下并不需要考慮移植性問題，此時采用SQL來完成業(yè)務(wù)邏輯是比較方便的處理方式。

采用存儲過程來完成業(yè)務(wù)邏輯最大的好處是性能會比較好，但是這也取決于業(yè)務(wù)規(guī)模的大小，如果業(yè)務(wù)規(guī)模過大，那么性能會下降的比較厲害。而早期的數(shù)據(jù)存儲規(guī)模比較小，所以采用存儲過程的方式是比較方便的。

目前的Web開發(fā)已經(jīng)到了大數(shù)據(jù)時代、云計算時代，業(yè)務(wù)類型和業(yè)務(wù)規(guī)模都有了較大的變化，尤其是大數(shù)據(jù)時代下NoSql數(shù)據(jù)庫的廣泛采用，使用SQL語句來完成業(yè)務(wù)邏輯的情景就更少了。而且，目前的程序大部分都是分布式方式，采用Sql存儲過程的方式來處理業(yè)務(wù)邏輯會非常麻煩，而且會導(dǎo)致整個項目的移植性和可讀性都嚴重下降。

目前在傳統(tǒng)企業(yè)的開發(fā)團隊中采用Sql來處理業(yè)務(wù)邏輯的情況比較常見，因為大部分傳統(tǒng)企業(yè)的數(shù)據(jù)庫還依然是關(guān)系型數(shù)據(jù)庫，而且不存在移植性要求，這種固定場景下的開發(fā)是完全可以使用Sql來處理業(yè)務(wù)邏輯的。未來使用Sql處理業(yè)務(wù)邏輯的情況也有一定的應(yīng)用場景，所以學(xué)習(xí)存儲過程的編寫還是有一定必要的。

我的研究方向是大數(shù)據(jù)和人工智能，目前也在帶大數(shù)據(jù)方向的研究生，我會陸續(xù)在頭條上寫一些關(guān)于大數(shù)據(jù)方面的文章，感興趣的朋友可以關(guān)注我的頭條號，相信一定會有所收獲。

如果有大數(shù)據(jù)方面的問題，也可以咨詢我。

謝謝！