java項目總結報告（精選5篇）

java項目總結報告 篇1

　　項目的框架：

　　先由通訊服務器(LISServer)開一個8088端口，當接收到客戶端發送的內容，然后將 行解析，然后根據解析出的內容作出相應的回應，這些回應是利用jDBC從數據庫掉出 在與數據庫連接時要用到一個數據庫連接池，連接池的作用是用于避免頻繁的鏈接數據 庫，這樣可以提高對用戶的回應效率。

　　用到的類有：

　　LISServer：啟動服務器并監聽8088端口

　　DispatchSocket：一個多線程的類，負責處理每個客戶端的請求

　　Requset：請求類，負責客戶端發送的請求處理

　　Response：響應類，負責將數據輸出到客戶端

　　WebAppConfigManager：一個負責讀取web.xml文件的類，同時生產對應的數據對象， 該數據包含在WebApp類型的對象里，單例模式類

　　WebApp： 對應xml文件里的節點的類

　　ServletMapping ：對應xml文件里的節點的類

　　BusinessServlet ：對應xml文件里的節點的類

　　ConfigDataSource ：對應xml文件里的節點的類

　　Super ：業務抽象類

　　CCB ：建設銀行業務類

　　ICBC ：工商銀行業務類

　　BaseDao ：業務接口類

　　InterestBean ：數據庫ccb表格對應的映射類

　　MyUser ：數據庫myuser表格對應的映射類

　　DBUtil ：連接數據庫操作類

　　MyUserDao ：負責對myuser表格操作的類

　　CCBDao ：CCB業務處理類，負責對數據庫數據操作

　　ICBCDao：ICBC業務處理類，負責對數據庫數據操作

　　LogInfo ：日志文件類

　　用到的技術和資料：1.網絡編程應用2.IO流操作應用3.字符串分解應用4.XML解析(JDOM、DOM4J)應用5.JDBC連接數據庫和數據庫操作應用6.JUnit測試用例應用7.反射技術應用8.工廠模式應用 9.集合應用 10.數據庫連接池應用 11.持久層應用 12.多線程應用 13.日志文件應用14.接口、抽象類應用 15.面向接口，面向抽象，面向父類編程應用 16.properties配置文檔。

　　在這個項目里我知道了團隊的合作是很重要的一個元素，一個完美的項目是離不開團隊的，而團隊的分工可以造就一個完美的項目，團隊里的每一個成員都是不可缺少的一個部分，我們在做的這個項目時犯了個很大的錯誤，就是每個成員都是自己搞自己的，只管把自己的搞好就行了，從來沒有想過其他組員的完成是怎樣的。這是一個很大的失誤。相信在以后我們會很好的發揮出團隊的優勢。還有就是在項目辯答中老師說的很對，我們只知道學習一些書上的那些很淺很淺的知識，在學習中老師只是把學習的方向給我們指出，其他就要靠自己去鉆自己去研究。不是什么都靠老師說的。還有就是在答辯中出了很多答辯題，這些題都可以讓我們提升的，在這些題里也可以發現我們的不足之處從而彌補它。我們要做到在項目中學習，在總結中學習，在答辯中完善自己。

java項目總結報告 篇2

　　在通過將近一個月的項目中，使我學到咯很多的東西，也讓我看到了我自己的一些在知識上不足，也將使我在后面java web的學習中還要更加努力，以便在以后能找到自己適意的工作，也不枉費在朗沃9個多月的學習，在這次項目中讓我學到了很多的東西，不只是代碼上的知識，也學諜咯java框架上的一些基本東西，還有層次結構的好處和又來，比如：MVC思想，MVC的又來有開始的兩層結構到三成結構的過度以及兩層結構的優缺點，以及現在流行的三層結構的優缺點，DAO模式的應用，對象的封裝，socket通信的原理以及用socket發送對象等很多的知識點，怎樣實現封裝使得更好的保護數據，實現java的三大特點，使代碼的耦合度降低提高內聚力類和類之間的依賴性降低使模塊和模塊之間的層次分明，實現代碼的復用和實現結構的復用使得開發一個系統的性能更加的優異。

　　在這次項目中使我對java面向對象的認識有了更時刻的印象，對“萬物皆為對象岜整個理念有更深層次的理解，通過和老師的交流和上網了解的一些知識，其實搞軟件的實質并不使在代碼上實現一個什么什么的功能，你只要愿意去著你用你所學的知識肯定能夠實現某一個功能，但學軟件的最根本使分析和設計，所以現在市面上會設計的人才使最來錢的人，在軟件開發的生命周期中編碼其實使占很小一部分工作，數據庫設計人員和java的框架技術人員使很賺錢的，也只有對在對象上有更多的了解你才能從代碼層次上上升為另一種理念過后你才能在以后的編碼中設計出更加優異和性能更高的代碼，也只有這樣那么你將來才有可能成為一個合格的程序員（不時編碼高手），在二個項目中的開發中使我團隊開發軟件上有了了解，也使我了解了在團隊開發軟件的時候的一些注意點，不能隨便更改類名，方法名悻變量及其修飾符，如果你一時興起該了的話那么在項目融合的時候問題機會層出不窮，就有可能使你的項目失敗，所以規范時很重要的，代碼的規范將很大層次上的說明你對代碼的熟念度。

　　在這次項目中使我對層次模型有了了解，在你那到一個項目文檔的時候你比不使馬上就開始編碼而是，找到每個層次上類，找到邊界類，根據相應的業務設計出數據庫原型，在數據庫原型出來之后在設計數據庫的表和表之間的關系，只有層次模型在你腦海中有深刻的印象的時候那么你的編碼當然也就很順利的實現，層次模型一旦建立那么你代碼上實現就圍繞這個架構來寫，那么你的系統才有可能成功，這樣在添加業務或者使更改業務時才很方便更改一個地方不會影響到其他的層次，這樣才有可能提高你系統的靈活性和擴展性，這也時衡量一個系統好壞的標準，在這次項目開發中用到咯大量的配置文件比如：用屬性文件來建立socket連接，用xml文件在找業務類，這樣有使我對配置文件的好處又有了一定的了解：合理的使用配置文件時提高代碼靈活性的一個方面，在建立套節字連接的時候用配置文件可以很方便的更改我在那個端口號上建立連接，在看不到源代碼的時候我也可以更改在其他端口上建立socket連接，在業務的時候用xml文件來找相應的業務類，這樣就可以在還要添加業務的時候只需要在xml文件中在添加業務，在寫起相應的代碼就可以實現，用配置文件找業務還又一個好處就是在調用業務的時候不用對業務類靜態的創建一個對象，而是用反射的方式找到調用那個方法，而是在程序執行的時候在創建對象在對象用完之后在釋放資源，這樣就可以減少電腦內存的消耗，使得程序的性能更加優異。

　　同時也增強了代碼的靈活性。

　　在用JDBC獲去數據庫連接對象的時候，其實時很有學文的咯，你如果在用連接對象的時候就要數據庫建立連接對象，在用完諸后就關閉連接對象，在很多用戶同時來運行你的系統的時候，就將產生很多的連接對象，這樣有使得你的系統性能降低，很好的解決辦法就是用數據庫連接池：在程序啟動的時候就建立最大連接和最小連接，當多用戶請求的時候只需從數據庫連接池中那出連接對象，這樣就可以減少多次連接對象，開始在最大連接對象和最小領接對象的選擇上又有了問題，創建最大連接時多少呢？最小連接有是多少呢？如果一開始最大連接數過多，而用戶有很少那么就浪費資源，并且系統啟動將會很慢，如果最大連接數過少那么程序啟動很快但在啟動后運行程序時有會很慢，最小連接數如果很小，那么在很多客戶訪問的時候將會很慢，合理利用數據庫連接池將會很大部分的提高程序的性能、在這次項目還用到了日志文件來記錄錯誤信息，在這次項目中還用到了很多的知識點我就不一一的在這里列舉了。

　　順便給大家幾道面試題（是前面部的同學給我說的）：

　　1、談談final、 finally、 finalize的區別。

　　2、HashMap和Hashtable的區別。

　　3、說說你對ejb的認識。

　　4、GC是什么？ 為什么要有GC？

　　5、談談你對抽象類與接口認識？

java項目總結報告 篇3

　　時間如梭，兩周過得真快。

　　前幾天伍老說由于教材未到項目要延遲一周突然教材到了，我們馬上要結束項目開始新的起點了。

　　聽很多同學說很想補習一下JAVA結果沒有機會了。

　　其實這就是所謂的鏈帶反應。

　　因為大家都知道在項目開發時遇到很多問題知道原來學得是那么的不認真，不刻苦。

　　這些都讓我意識到在Web時應該認真的學習。

　　這可能是我在項目中體會最深的吧！

　　下面簡單的談談我的項目感想吧。

　　首先想談的是我們為什么會做這個項目，很多培訓學校都會在每學完一個階段就有項目的任務。

　　原來我所在的那個培訓學校也不例外。

　　原來對項目不怎么重視，覺得那是作業只要能把項目提交了就OK啦。

　　現在仔細想想往往不止那么簡單。

　　只要但我們了解它的目的才能更加的學習他。

　　我們現在是JAVA OO所以我認為學校的這次項目主要是想讓我們對代碼熟練，增加我們的代碼量，JAVA OOP的認識。

　　胡老師說現在的項目與原來的目的有所不同。

　　比如現在我們連《項目需求開發說明書》都沒寫。

　　所有很多同學存在對項目不了解，當然這主要也是我們自己的原因。

　　我們現在完成項目后只要能達到學校當初的目的就完成90%了。

　　我個人覺得其實對JAVA OOP的理解是最重要的。

　　其次談談我是怎么做的這個項目，學校本次的主要任務的讓我們熟悉代碼，了解JAVA OOP 所以我們沒有寫《項目需求開發說明書》。

　　記得第一次張老師說這個項目時當時腦袋暈乎乎的對這個項目不怎么了解。

　　現在終于完成了項目當然對項目也有了一些了解。

　　項目過程中我們主要是在上理論課時張老師講解PPT，PPT上時我們當天項目中能用到的知識點并且都是經典。

　　在這期間我和其他同學一樣有些痛苦開始對項目不了解，然后到了解項目整個流程最后思考為什么學校會這么設計這個項目。

　　這些都是很讓人很痛苦的。

　　最后我們通過項目有哪些感想，第一知識點：這和很多同學一樣，在項目過程中感覺自己不管是在在代碼方面還是思想方面都欠缺的太多了，知識點掌握的不牢靠。

　　第二JAVA OOP。

　　沒有理解OOP中某些概念或者對它們了解不深。

　　第三項目設計：在DAO模式時我們用到了連接池，雖然代碼很簡單但是一個項目沒有它時很難的。

　　并且我們項目中用到了反射+配置文件進行動態的執行出現，一個不錯的項目設計思想。

　　第四課外擴展：雖然這個代碼并不多但里面的深度以及知識點是我原來根本沒有想到的。

　　然而這些我原來都沒有意識到。

　　充分說明了課外擴展得太少了。

　　這些也是剛才我所說的鏈帶反應。

　　當然還有很多很多新的知識點總之讓我對JAVA對項目有了新的認識！

java項目總結報告 篇4

　　要開始入手一個新的javaweb應用應該遵循這樣一個原則

　　1、首先是整體框架，也就是通常所說的三層構架：

　　數據庫+應用服務器+應用

　　2、其此是框架各個部分所處的環境，就是數據庫，應用服務器的os都是什么，怎么溝通，怎么在對應os下調配數據庫以及應用服務器。

　　3、再次應該是應用服務器和數據庫的連接，這點很重要，要查找相關資料怎么配置應用服務器和數據庫連接，以及使用的數據庫連接池技術。

　　4、然后才是了解應用的構架，也就是所謂的項目源碼了，具體使用了那種mvc模式，使用了什么日志工具，測試工具、編譯工具，還用要是你去熟悉一個公司的項目的話，這個公司可能有自己的web相干開發工具

　　我用visio做了一個圖形應該是這樣的順序

　　用我最近的具體例子來做說明吧：

　　1。首先是3層構架

　　數據庫是mysql，應用服務器是resin，應用基本上是struts+hibernate，這里明確了學習目標應該是：

　　mysql的相關使用方法

　　resin的相關使用方法

　　2。其次是os數據庫和應用服務器放在一臺主機上，OS是linux，但是日常的開發環境是windows，所以用到了常用的ssh對主機進行管理，這里明確了學習目標應該是：

　　Unix相關命令

　　Ssh的.使用方法

　　3。然后是數據庫和應用服務器的連接方法，使用mysql的jdbc接口，這里明確了學習目標應該是：

　　Resin對數據庫連接的配置方法

　　Mysql對數據去連接有什么要求

　　4。最后是應用代碼層

　　這層應該是最后學習，但是我們往往習慣對整個系統沒有弄清框架就開始這層的研究，這就導致在研究中不斷出現有關框架的各種問題，而又要中斷當前學習，開始查找另一個資料。

　　我開始就犯了這個毛病，所以進度緩慢。

　　這里我的項目使用了hibernate+struts作為基本框架，用Ant進行編譯發布工作，使用eclipse作為ide，另外用到的java工具有jfreechart，quartz等，再有自己公司開發的web框架工具包

　　這里明確了學習目標應該是邊參照源碼一邊學習Struts，hibernate，ant，eclipse，jfreechart，quartz，自己公司的工具包，然后再在數據庫的角度對整個業務邏輯做出理解。

　　當然，以上四步中肯定是有些工具和技術已經掌握了，我們所要面向的是我們沒有掌握方面，然后最終達到掌握系統的目的！要注意我們的目的是上手新平臺不是學習新技術！

java項目總結報告 篇5

　　這是一次比較完整的團隊合作項目，它要求團隊各成員對系統的主體設計搭成一定的共識，這包括數據庫設計，需求分析，以及其它一些細節，因此在編碼之前的準備工作一定要充分。

　　在設計之前，我們兩組對于數據庫的設計進行了激烈的討論，最后在一些關鍵的問題上統一了意見。接下來的工作便是需求分析，具體結構設計，并制訂小組項目詳細計劃，項目的進行將嚴格按照所制訂的計劃執行。然后小組成員對各自的數據庫進行了設計，并且以數據字典的形式進行了共享。

　　企業級人力資源系統分為十個子系統：機構編制管理、人員信息管理、人事檔案管理、考勤管理、薪資福利管理、社會保障管理、招聘管理、合同管理、查詢統計管理、系統管理。

　　我負責人員信息管理子系統，這方面需要處理的業務邏輯比較少，表單比較多，要把握好與其它子系統的關聯。員工基本信息表是與其它子系統關聯的橋梁，大部分表都涉及到與基本信息表的外鍵關聯。其中，職員編號(employeeId)是作為外鍵關聯的字段，我給它設置了自增長。有人認為在企業里，職員編號應該是有一定規律的數字，而不應該設置自增長。這樣的是想法很符合實際情況，后來我和兩個組長討論，認為自增長可以保證數據的唯一性，非自增長的主鍵在增加時可能遇到不可知的問題，并且其他組員的數據庫已經設計好，改起來就麻煩了。因此最終職員編號采用了自增長。

　　有了上面的共識，接下來的重要工作便是依次完成表的增刪改查、數據校驗。其中，分頁和批量刪除是我計劃最后完成的部分，并且一定要完成。

　　基本數據校驗按各數據格式進行，例如手機號、e-mail等。另一方面要對職員編號與姓名的一致性，職員編號的存進行驗證，這些通過DAO里面的方法實現，針對出錯，用JS給出友好的提示。

　　在做好基本功能的前提下，爭取做出特色。我嘗試寫了Hibernate分頁、批量刪除的代碼，最后都測試成功。同時加入了JS控件，對于一些有特殊格式要求的字段，防止用戶填寫錯誤(比如日期的填寫格式為yyyy-mm-dd)，使系統更加人性化。經過討論，對員工基本信息主表及與其關聯的所有表，配置級聯刪除。當主表信息被刪除時，與之外鍵關聯的子表信息同時被刪除。

　　回顧這段歷程，遇到了一些瓶頸，例如批量刪除時如何有效的處理選中的id，要明白它得到的是一個String，需要轉化成int就好辦了。關于分頁，我也是琢磨了好久。在網上看了不少實例，具體實現起來還是一頭霧水。就在項目驗收的前兩天晚上，我決定自己寫的試試。第一個方法是需要獲取表里面總記錄數count，按照套路執行hql，我這樣處理了結果：

　　count = list.size;結果出了問題。數據庫里有6條記錄，結果打印出count為1。在這里折騰了好久，后來打印list為[6]，這下才明白list.size得到的是list里元素的個數，這個元素是6 ，我需要獲取的是元素的是值(基礎知識薄弱)。明白這點就好辦了，最后我是這樣處理的

　　String a = list.get(0).toString; //獲取list第一個元素(對象)，并轉換成String

　　count = Integer.parseInt(a); //將a轉換成int，得到count 這樣做分頁的第一步就完成了。第二天早上比較順利的完成了剩下的代碼并測試成功。 相比網上的分頁代碼，總的來說我寫的很容易看懂，至于它有什么問題目前還不知道。

　　通過這次項目經驗，我明白了只要想到了，就一定可以做到。不要畏懼，困難并不像想像中的那么可怕。一味的逃避將得不到真正的鍛煉。要時刻和隊友交流，分享成果。兩個人總比一個人知道的多。