當(dāng)前位置：首頁 > 编程资源 > 综合教程 >内容正文

综合教程

java J2EE 分层设计思想及各个文件命名规范

發(fā)布時(shí)間：2023/12/1 综合教程 28 生活家

生活随笔收集整理的這篇文章主要介紹了 java J2EE 分层设计思想及各个文件命名规范小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

分層設(shè)計(jì)思想

通常在設(shè)計(jì)項(xiàng)目時(shí)候總是會(huì)采用MVC設(shè)計(jì)模式來實(shí)現(xiàn)的，這樣子思路清晰，方便以后項(xiàng)目的維護(hù)和擴(kuò)展。

最常見的分層結(jié)構(gòu)如下:

表現(xiàn)層:主要給客戶端顯示的

服務(wù)層:為客戶提供服務(wù)和功能

領(lǐng)域?qū)?即領(lǐng)域模型，一些javabean之類的對(duì)象

DAO層:數(shù)據(jù)訪問層

設(shè)計(jì)指導(dǎo)原則:

1.上層總是依賴下層，不要跨層訪問

2.一切從服務(wù)層出發(fā)，從系統(tǒng)需要提供的功能進(jìn)行分析，確定service接口中的方法

3.系統(tǒng)最核心的設(shè)計(jì)就是講兄臺(tái)那個(gè)的實(shí)體劃分為領(lǐng)域模型，在此基礎(chǔ)上設(shè)計(jì)DAO層

4.每個(gè)接口的職責(zé)范圍明確有界

DAO:?xxxDAO,?xxxDAOImpl

Service：xxxService,?xxxServiceImpl

Action：

訪問順序應(yīng)該是這樣的:

View---->Action--->Service--->DAO--->DB

舉個(gè)例子(MVC):

顧客去飯店吃飯，面對(duì)的肯定是服務(wù)員顧客對(duì)服務(wù)員說我要吃什么什么。服務(wù)得知顧客的請(qǐng)求之后，就給廚師說你給我做這些菜給我，廚師(巧婦難為無米之炊)對(duì)采購員說你去超市給我買這些原料過來，采購員就屁顛屁帶你的到超市這個(gè)大倉庫拿原料過來了。

如果不是使用分層思想設(shè)計(jì)的話:

如果是小餐館的話可能就會(huì)出現(xiàn)這種情況，顧客上來直接問服務(wù)員(這個(gè)服務(wù)員也就是老板娘也是廚師，她啥都干)我要什么什么菜，服務(wù)員就去廚房自己買菜自己做菜，然后再自己端菜服務(wù)顧客。

三層架構(gòu)已經(jīng)學(xué)了一段時(shí)間,一直想做一個(gè)比較完整、比較完美的總結(jié)。但是左思右想，不知道如何下筆。都說萬事開頭難嘛，今天整理了一下凌亂的思路，哎，還是沒整理好，想到哪就說到哪吧。

三層架構(gòu)

初學(xué)者很不理解：

1，什么是三層？

2，為什么使用三層？

3，三層與以往使用的兩層相比有什么不同？它的優(yōu)勢(shì)在哪里？

4，如何學(xué)好三層？如何應(yīng)用三層？

……

這篇博客里我會(huì)給大家一一解釋一下，略懂皮毛忘大家見諒！！！

米老師一直強(qiáng)調(diào)：讓學(xué)習(xí)和生活結(jié)合，把學(xué)習(xí)和生活聯(lián)系，這樣的學(xué)習(xí)才叫會(huì)學(xué)習(xí)，會(huì)生活。

對(duì)于三層我左思右想，如何與實(shí)際相聯(lián)系。好嘛，昨晚突然有了“靈感”。還記得大話設(shè)計(jì)模式里第23章大鳥和小菜吃羊肉串的故事——由在小攤吃到飯店吃引來的一個(gè)命令模式（當(dāng)然今天不是研究命令模式）。服務(wù)員、廚師、采購員。

這不就是個(gè)典型的三層架構(gòu)嗎？？？(⊙?o?⊙?)啊！哈哈（這個(gè)后面再做解釋）

先了解：

1,什么是三層？

UI(表現(xiàn)層):主要是指與用戶交互的界面。用于接收用戶輸入的數(shù)據(jù)和顯示處理后用戶需要的數(shù)據(jù)。

BLL:(業(yè)務(wù)邏輯層):UI層和DAL層之間的橋梁。實(shí)現(xiàn)業(yè)務(wù)邏輯。業(yè)務(wù)邏輯具體包含：驗(yàn)證、計(jì)算、業(yè)務(wù)規(guī)則等等。

DAL:(數(shù)據(jù)訪問層):與數(shù)據(jù)庫打交道。主要實(shí)現(xiàn)對(duì)數(shù)據(jù)的增、刪、改、查。將存儲(chǔ)在數(shù)據(jù)庫中的數(shù)據(jù)提交給業(yè)務(wù)層，同時(shí)將業(yè)務(wù)層處理的數(shù)據(jù)保存到數(shù)據(jù)庫。（當(dāng)然這些操作都是基于UI層的。用戶的需求反映給界面（UI），UI反映給BLL，BLL反映給DAL，DAL進(jìn)行數(shù)據(jù)的操作，操作后再一一返回，直到將用戶所需數(shù)據(jù)反饋給用戶）

每一層都各負(fù)其責(zé)，那么該如何將三層聯(lián)系起來呢？

1>單項(xiàng)引用（見下圖）

2>這時(shí)候?qū)嶓w層（Entity）來了。（注：當(dāng)然，實(shí)體層的作用不止這些）

Entity(實(shí)體層)：它不屬于三層中的任何一層，但是它是必不可少的一層。

Entity在三層架構(gòu)中的作用：

1,實(shí)現(xiàn)面向?qū)ο笏枷胫械?#034;封裝";

2，貫穿于三層，在三層之間傳遞數(shù)據(jù);

（注：確切的說實(shí)體層貫穿于三層之間，來連接三層）

3，對(duì)于初學(xué)者來說，可以這樣理解：每張數(shù)據(jù)表對(duì)應(yīng)一個(gè)實(shí)體，即每個(gè)數(shù)據(jù)表中的字段對(duì)應(yīng)實(shí)體中的屬性（注：當(dāng)然，事實(shí)上不是這樣。為什么？1＞，可能我們需要的實(shí)體在數(shù)據(jù)表對(duì)應(yīng)的實(shí)體中并不存在；2＞，我們完全可以將所有數(shù)據(jù)表中的所有字段都放在一個(gè)實(shí)體里）

4，每一層（UI—>BLL—>DAL）之間的數(shù)據(jù)傳遞（單向）是靠變量或?qū)嶓w作為參數(shù)來傳遞的，這樣就構(gòu)造了三層之間的聯(lián)系，完成了功能的實(shí)現(xiàn)。

但是對(duì)于大量的數(shù)據(jù)來說，用變量做參數(shù)有些復(fù)雜，因?yàn)閰?shù)量太多，容易搞混。比如：我要把員工信息傳遞到下層，信息包括：員工號(hào)、姓名、年齡、性別、工資．．．．用變量做參數(shù)的話，那么我們的方法中的參數(shù)就會(huì)很多，極有可能在使用時(shí)，將參數(shù)匹配搞混。這時(shí)候，如果用實(shí)體做參數(shù)，就會(huì)很方便，不用考慮參數(shù)匹配的問題，用到實(shí)體中哪個(gè)屬性拿來直接用就可以，很方便。這樣做也提高了效率。

（注：這里為什么說可以暫時(shí)理解為每個(gè)數(shù)據(jù)表對(duì)應(yīng)一個(gè)實(shí)體？？答：大家都知道，我們做系統(tǒng)的目的，是為用戶提供服務(wù)，用戶可不關(guān)心你的系統(tǒng)后臺(tái)是怎么工作的，用戶只關(guān)心軟件是不是好用，界面是不是符合自己心意。用戶在界面上輕松的增、刪、改、查，那么數(shù)據(jù)庫中也要有相應(yīng)的增、刪、改、查，而增刪改查具體操作對(duì)象就是數(shù)據(jù)庫中的數(shù)據(jù)，說白了就是表中的字段。所以，將每個(gè)數(shù)據(jù)表作為一個(gè)實(shí)體類，實(shí)體類封裝的屬性對(duì)應(yīng)到表中的字段，這樣的話，實(shí)體在貫穿于三層之間時(shí)，就可以實(shí)現(xiàn)增刪改查數(shù)據(jù)了）

綜上所述:三層及實(shí)體層之間的依賴關(guān)系:

思想來源于生活：

服務(wù)員：只管接待客人；

廚師：只管做客人點(diǎn)的菜；

采購員：只管按客人點(diǎn)菜的要求采購食材；

他們各負(fù)其職，服務(wù)員不用了解廚師如何做菜，不用了解采購員如何采購食材；廚師不用知道服務(wù)員接待了哪位客人，不用知道采購員如何采購食材；同樣，采購員不用知道服務(wù)員接待了哪位客人，不用知道廚師如何做菜。

他們?nèi)呤侨绾温?lián)系的？

比如：廚師會(huì)做：炒茄子、炒雞蛋、炒面——此時(shí)構(gòu)建三個(gè)方法（?cookEggplant()、cookEgg()、cookNoodle())

顧客直接和服務(wù)員打交道，顧客和服務(wù)員（UI層）說：我要一個(gè)炒茄子，而服務(wù)員不負(fù)責(zé)炒茄子，她就把請(qǐng)求往上遞交，傳遞給廚師（BLL層），廚師需要茄子，就把請(qǐng)求往上遞交，傳遞給采購員（DAL層），采購員從倉庫里取來茄子傳回給廚師，廚師響應(yīng)cookEggplant()方法，做好炒茄子后，又傳回給服務(wù)員，服務(wù)員把茄子呈現(xiàn)給顧客。

這樣就完成了一個(gè)完整的操作。

在此過程中，茄子作為參數(shù)在三層中傳遞，如果顧客點(diǎn)炒雞蛋，則雞蛋作為參數(shù)（這是變量做參數(shù)）。如果，用戶增加需求，我們還得在方法中添加參數(shù)，一個(gè)方法添加一個(gè)，一個(gè)方法設(shè)計(jì)到三層；何況實(shí)際中并不止設(shè)計(jì)到一個(gè)方法的更改。所以，為了解決這個(gè)問題，我們可以把茄子、雞蛋、面條作為屬性定義到顧客實(shí)體中，一旦顧客增加了炒雞蛋需求，直接把雞蛋屬性拿出來用即可，不用再去考慮去每層的方法中添加參數(shù)了，更不用考慮參數(shù)的匹配問題。

這樣講，不知道大家是不是可以明白。（待會(huì)實(shí)例解釋吧）

2，為什么使用三層？

使用三層架構(gòu)的目的：解耦！！！

同樣拿上面飯店的例子來講：

（1）服務(wù)員（UI層）請(qǐng)假——另找服務(wù)員；廚師（BLL層）辭職——招聘另一個(gè)廚師；采購員（DAL）辭職——招聘另一個(gè)采購員；

（2）顧客反映：1>你們店服務(wù)態(tài)度不好——服務(wù)員的問題。開除服務(wù)員；

2>你們店菜里有蟲子——廚師的問題。換廚師；

任何一層發(fā)生變化都不會(huì)影響到另外一層！！！

3，與兩層的區(qū)別？？

兩層：

（當(dāng)任何一個(gè)地方發(fā)生變化時(shí)，都需要重新開發(fā)整個(gè)系統(tǒng)。“多層”放在一層，分工不明確耦合度高——難以適應(yīng)需求變化，可維護(hù)性低、可擴(kuò)展性低）

三層：

（發(fā)生在哪一層的變化，只需更改該層，不需要更改整個(gè)系統(tǒng)。層次清晰，分工明確，每層之間耦合度低——提高了效率，適應(yīng)需求變化，可維護(hù)性高，可擴(kuò)展性高）

綜上：三層架構(gòu)的

優(yōu)勢(shì)：1，結(jié)構(gòu)清晰、耦合度低,2，可維護(hù)性高，可擴(kuò)展性高；3，利于開發(fā)任務(wù)同步進(jìn)行；容易適應(yīng)需求變化

劣勢(shì)：1、降低了系統(tǒng)的性能。這是不言而喻的。如果不采用分層式結(jié)構(gòu)，很多業(yè)務(wù)可以直接造訪數(shù)據(jù)庫，以此獲取相應(yīng)的數(shù)據(jù)，如今卻必須通過中間層來完成。

2、有時(shí)會(huì)導(dǎo)致級(jí)聯(lián)的修改。這種修改尤其體現(xiàn)在自上而下的方向。如果在表示層中需要增加一個(gè)功能，為保證其設(shè)計(jì)符合分層式結(jié)構(gòu)，可能需要在相應(yīng)的業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層中都增加相應(yīng)的代碼

3、增加了代碼量，增加了工作量

4,三層的具體表現(xiàn)形式？？

UI：

（大家不要誤會(huì)，UI層不只是一個(gè)個(gè)用戶界面，也是需要有代碼的）

(1,功能：用戶輸入數(shù)據(jù)、反饋給用戶數(shù)據(jù)；2,大家觀察代碼:沒有涉及到業(yè)務(wù)邏輯，直接傳參、函數(shù)、方法調(diào)用，沒有涉及到與數(shù)據(jù)庫打交道的SQL語句和ADO.net)

BLL：

（1，BLL是表示層與數(shù)據(jù)訪問層之間的橋梁，負(fù)責(zé)數(shù)據(jù)處理、傳遞；2，大家觀察代碼，沒有涉及到界面上的控件，沒有涉及到SQL語句和ADO.net）

DAL：

(1,以上是DAL層中DbUtil類、user_DA類和workRecord_DA類中的代碼;2,大家觀察代碼，沒有涉及到界面控件，沒有涉及到業(yè)務(wù)邏輯；只有與數(shù)據(jù)庫打交道的SQL語句和ADO.net)

Entity（Model）層：

（定義了實(shí)體類user）

觀察以上三層：

1，實(shí)體類user作為參數(shù)貫穿于三層之間；

2，通過傳參、方法調(diào)用來實(shí)現(xiàn)功能；

3，各層之間各負(fù)其責(zé)；互不影響

對(duì)比兩層結(jié)構(gòu)，讓大家深刻體會(huì)三層的極大好處：

還是以機(jī)房收費(fèi)系統(tǒng)的登陸為例：

（觀察上面的兩層的代碼：將業(yè)務(wù)邏輯、數(shù)據(jù)訪問都展現(xiàn)在用戶表現(xiàn)層，當(dāng)需求需要改變時(shí)，需要改變整個(gè)系統(tǒng)。比如，我把文本框txtPassWord的名稱改為txtPwd的話，大家觀察一下得需要更改多少地方。這樣的改動(dòng)算是小的，如果真的有業(yè)務(wù)需求上的改動(dòng)才叫麻煩復(fù)雜，程序員不跳樓才怪。呵呵、、開個(gè)玩笑）

與如此難以適應(yīng)需求變化的兩層相比，大家再次觀察三層代碼，再次思考，三層架構(gòu)有什么好處呢？自己思考。。。。。

自己去發(fā)掘吧！！！

總結(jié)：

首先，JavaEE開發(fā)分為表示層、業(yè)務(wù)層、持久化層。而表示層和持久化層需要做的功能比較單一。

1、表示層(action、controller)需要做的就是接受用戶請(qǐng)求、調(diào)用業(yè)務(wù)進(jìn)行處理、返回需要響應(yīng)的頁面或者結(jié)果，當(dāng)前，如果有參數(shù)，就攜帶著。

2、持久化層(dao、repository)需要做的就是對(duì)數(shù)據(jù)庫的操作，不同框架有不同的處理。但是總而言之，無非就是增刪改查操作，當(dāng)然，有時(shí)候需要很復(fù)雜的sql查詢。

3、業(yè)務(wù)邏輯層(service)，這個(gè)就是不同公司的主要業(yè)務(wù)核心，不同的公司有不同的業(yè)務(wù)。

　　因此，表示層和持久化層用不同的框架進(jìn)行開發(fā)，而業(yè)務(wù)層就需要開發(fā)人員根據(jù)公司的情況進(jìn)行業(yè)務(wù)開發(fā)。

然后，命名規(guī)則就是看公司的具體要求，當(dāng)然，一些開發(fā)過程中也有一些約定成熟的規(guī)定，比如包名小寫，并且公司域名反寫等等。

代碼編寫規(guī)范目的：能夠在編碼過程中實(shí)現(xiàn)規(guī)范化，為以后的程序開發(fā)中養(yǎng)成良好的行為習(xí)慣。
代碼編寫規(guī)范使用范圍：J2EE項(xiàng)目開發(fā)。

包命名規(guī)范：
目的：包的命名規(guī)范應(yīng)當(dāng)體現(xiàn)出項(xiàng)目資源良好的劃分

servlet類所在包命名規(guī)范：公司名稱.開發(fā)組名稱.項(xiàng)目名稱.web.servlet
例如：net.linkcn.web.servlet

自定義標(biāo)簽類所在包命名規(guī)范：公司名稱.開發(fā)組名稱.項(xiàng)目名稱.web.tags
例如：net.linkcn.web.tags

過濾器類所在包命名規(guī)范：公司名稱.開發(fā)組名稱.項(xiàng)目名稱.web.filter
例如：net.linkcn.web.filter

Action類所在包命名規(guī)范：公司名稱.開發(fā)組名稱.項(xiàng)目名稱.web.struts.action
例如：net.linkcn.web.struts.action

ActionForm類所在包命名規(guī)范：公司名稱.開發(fā)組名稱.項(xiàng)目名稱.web.struts.form
例如：net.linkcn.web.struts.form

Javabean所在包命名規(guī)范：公司名稱.開發(fā)組名稱.項(xiàng)目名稱.web.struts.service.impl
例如：net.linkcn.web.service.impl

Javabean實(shí)現(xiàn)接口命名規(guī)范：公司名稱.開發(fā)組名稱.項(xiàng)目名稱.web.service
例如：net.linkcn.web.service

DAO類所在包命名規(guī)范：公司名稱.開發(fā)組名稱.項(xiàng)目名稱.dao.impl
例如：net.linkcn.dao.impl

DAO類所實(shí)現(xiàn)的接口在包中命名規(guī)范：公司名稱.開發(fā)組名稱.項(xiàng)目名稱.dao
例如：net.linkcn.dao

POJO類與hbm文件所在包命名規(guī)范：公司名稱.開發(fā)組名稱.項(xiàng)目名稱.dao.hbm
例如：net.linkcn.dao.hbm

全局公共類、接口類所在包命名規(guī)范：公司名稱.開發(fā)組名稱.項(xiàng)目名稱.global
例如：net.linkcn.global

全局工具類所在包命名規(guī)范：公司名稱.開發(fā)組名稱.項(xiàng)目名稱.util
例如：net.linkcn.util

類命名規(guī)范
基本命名規(guī)范：

類、接口命名
命名規(guī)范：以大寫字母開頭，如果有多個(gè)單詞，每個(gè)單詞頭字母大寫
例如：StudentInfo

接口命名
命名規(guī)范：以大寫字母"I"開頭，如果有多個(gè)單詞，每個(gè)單詞頭字母大寫
例如：IStudentInfo

接口實(shí)現(xiàn)類命名：
命名規(guī)范：將實(shí)現(xiàn)的接口名稱的首字母"I"去掉，以"Impl作為結(jié)尾"，如果有多個(gè)單詞，每個(gè)單詞頭字母大寫。
例如：StudentInfoImpl

J2EE+SSH框架命名規(guī)范

servlet類命名：
命名規(guī)范：以Servlet單詞結(jié)尾
例如：LoginServlet

POJO命名：
使用hibernate自動(dòng)生成的類即可

DAO類命名：
使用hibernate自動(dòng)生成的類即可

Action類命名：
命名規(guī)范：Action的命名以POJO名稱來制定，POJO名稱Action
例如：
一個(gè)POJO名稱為Diary，其對(duì)應(yīng)的action為DiaryAction

ActionForm類命名：
命名規(guī)范：ActionForm的命名以POJO名稱來制定，POJO名稱Form
例如：
一個(gè)POJO名稱為Diary，其對(duì)應(yīng)的actioForm為DiaryForm

業(yè)務(wù)邏輯接口命名:
命名規(guī)范：業(yè)務(wù)邏輯接口的命名以POJO名稱來制定，IPOJO名稱Service
例如：
一個(gè)POJO名稱為Diary，其對(duì)應(yīng)的業(yè)務(wù)邏輯接口為IDiaryService

業(yè)務(wù)邏輯實(shí)現(xiàn)類命名:
命名規(guī)范：業(yè)務(wù)邏輯接口實(shí)現(xiàn)類的命名以POJO名稱來制定
例如：
一個(gè)POJO名稱為Diary，對(duì)應(yīng)的業(yè)務(wù)邏輯接口實(shí)現(xiàn)類名為DiaryServiceImpl

類變量命名：
命名規(guī)范：變量名首字母必須小寫，如果該變量名有多個(gè)單詞組成，后面的單詞首字母大寫，單詞與單詞之間不要使用"_"做連接，變量名訪問控制必須為私有，可以對(duì)其增加setter與getter方法。
例如：

private int studentAge;
public int getStudentAge(){
return studentAge;
}
public void setStudentAge(int studentAge) {
this.studentAge=studentAge;
}

常量命名：
命名規(guī)范：所有字母大寫，如果有多個(gè)單詞組成，單詞與單詞之間以” _“隔開。而且該變量必須是公共、靜態(tài)、final類型
例如：public static final String USER_NAME=”userName“;

方法命名
命名規(guī)范：首字母必須小寫，如果該變量名有多個(gè)單詞組成，后面的單詞首字母大寫，單詞與單詞之間不要使用"_"做連接。單詞不要使用名詞。
例如：public int checkLogin（String name,String pwd）{}

注釋規(guī)范：注釋規(guī)范是整個(gè)開發(fā)規(guī)范中最為重要的組成部分，必須嚴(yán)格執(zhí)行。
類的注釋：
作用：注釋整個(gè)類，簡單概述該類作用。
書寫規(guī)范：類的注釋必須寫在該類的聲明語法之前。在注釋中要描述該類的基本作用，作者，日期，版本，公司名稱，版權(quán)聲明。
格式：

/* *?
* 類功能描述：（大致描述類的功能）?
* @author：編寫者名稱
*?
* @version：類文件的版本號(hào) 從1.0開始（自己確定版本號(hào)的增改?
* 情況），修改情況（修改時(shí)間、作者、改動(dòng)情況）
*
* @see 包名.參考類名（列出父類，引入類，每個(gè)類占一行），如果有
* 可省略?
* 相關(guān)數(shù)據(jù)如：（便于理解本類的一些常量數(shù)據(jù)及某些數(shù)據(jù)的格式?
* 或認(rèn)為比較重要的數(shù)據(jù)，如果沒有可省略）?
*/?
類的聲明語法

例如：

/**
* Title:管理員模塊數(shù)據(jù)處理類 
* Description: 兩個(gè)數(shù)相加
* Copyright: Copyright (c) 2007
* Company:華騰軟件公司
*?
* @author 童金虎
*?
* @version $Revision: 1.7 $ $Date: 2007/07/08$?
*/
public class AdminDAO

變量、常量注釋：
作用：簡單描述該變量的意義。
書寫規(guī)范：變量注釋必須寫在變量定義之前，簡單描述其代表的意義。
格式：

/**?
* 變量功能描述：（大致描述變量的功能）
*/

例如：

/**
*定義年齡變量
*/
public int age;

方法注釋：
作用：對(duì)該方法功能簡單描述，其參數(shù)、返回值意義的注解。
書寫規(guī)范：方法注釋必須寫在方法定義之前。該注釋包括：方法其功能的簡單描述，方法的參數(shù)、返回值類型、返回值意義簡單的描述。
格式：

/**?
* 方法功能說明?
* @param args (參數(shù)類型可以寫在參數(shù)后，也可以省?
* 略。每個(gè)參數(shù)占一行)?
* @return 輸出參數(shù)（多種情況寫在同一行）?
* @see 類#參考方法（與此方法有調(diào)用關(guān)系的方法供參?
* 考，不必每個(gè)方法都完整列出，要選擇有意義的，每個(gè)?
* 方法占一行）?
* @exception 異常處理類（方法中能夠引發(fā)的異常，每?
* 個(gè)異常占一行）?
*/

例如：

/**
* 修改管理員密碼
* @param adminId 管理員編號(hào)
* @param oldPassword 舊密碼
* @param password 新密碼
* @return boolean 是否編輯成功
* @throws UserException
* @throws ServiceException
*/
public booleaneditAdminPassword(int adminId,String oldPassword,
String password) throws UserException,ServiceException;

Jsp頁面命名：
命名規(guī)范：jsp頁面名稱要以小寫字母開頭，如果有多個(gè)單詞組成，后面的單詞以大寫字母開頭。名稱要體現(xiàn)出該頁面的意義，最好能夠與模塊名稱聯(lián)系在一起。
例如：
login.jsp --登錄頁面
register.jsp --注冊(cè)頁面
message.jsp --客戶留言頁面

J2EE項(xiàng)目工程文件夾組織規(guī)范：
目的：規(guī)范學(xué)員web應(yīng)用程序的資源組織形式，形成良好的文件組織習(xí)慣。文件的組織形式應(yīng)當(dāng)體現(xiàn)模塊的劃分。
根據(jù)eclipse工具的特征，項(xiàng)目的目錄結(jié)構(gòu)為：

J2EE項(xiàng)目提交規(guī)范
項(xiàng)目完成時(shí)要將項(xiàng)目作為一個(gè)產(chǎn)品交付用戶，良好的項(xiàng)目組織規(guī)范可以使用戶可以方便的找尋項(xiàng)目中需要的資源，同時(shí)也是一個(gè)公司專業(yè)性的體現(xiàn)。項(xiàng)目提交時(shí)，要按照下列文件格式進(jìn)行提交。

項(xiàng)目主文件夾：
作用：存放項(xiàng)目其他資源文件。
命名規(guī)范：時(shí)間_班級(jí)編號(hào)_第X小組。
例如：070706_GS2T18_第四小組。

注：一個(gè)完整的項(xiàng)目中，數(shù)據(jù)庫必須有一定量的有效的測試數(shù)據(jù)來支持該程序的運(yùn)行

包的命名　

Java包的名字都是由小寫單詞組成。但是由于Java面向?qū)ο缶幊痰奶匦?#xff0c;每一名Java程序員都可以編寫屬于自己的Java包，為了保障每個(gè) Java包命名的唯一性，在最新的Java編程規(guī)范中，要求程序員在自己定義的包的名稱之前加上唯一的前綴。由于互聯(lián)網(wǎng)上的域名稱是不會(huì)重復(fù)的，所以程序員一般采用自己在互聯(lián)網(wǎng)上的域名稱作為自己程序包的唯一前綴。?
例如： net.frontfree.javagroup

類的命名

類的名字必須由大寫字母開頭而單詞中的其他字母均為小寫；如果類名稱由多個(gè)單詞組成，則每個(gè)單詞的首字母均應(yīng)為大寫例如TestPage；如果類名稱中包含單詞縮寫，則這個(gè)所寫詞的每個(gè)字母均應(yīng)大寫，如：XMLExample,還有一點(diǎn)命名技巧就是由于類是設(shè)計(jì)用來代表對(duì)象的，所以在命名類時(shí)應(yīng)盡量選擇名詞。　　?
例如： Circle

方法的命名

方法的名字的第一個(gè)單詞應(yīng)以小寫字母作為開頭，后面的單詞則用大寫字母開頭。?
例如： sendMessge

常量的命名

常量的名字應(yīng)該都使用大寫字母，并且指出該常量完整含義。如果一個(gè)常量名稱由多個(gè)單詞組成，則應(yīng)該用下劃線來分割這些單詞。?
例如： MAX_VALUE

參數(shù)的命名

參數(shù)的命名規(guī)范和方法的命名規(guī)范相同，而且為了避免閱讀程序時(shí)造成迷惑，請(qǐng)?jiān)诒M量保證參數(shù)名稱為一個(gè)單詞的情況下使參數(shù)的命名盡可能明確。

Javadoc注釋

Java除了可以采用我們常見的注釋方式之外，Java語言規(guī)范還定義了一種特殊的注釋，也就是我們所說的Javadoc注釋，它是用來記錄我們代碼中的API的。Javadoc注釋是一種多行注釋，以/**開頭，而以*/結(jié)束，注釋可以包含一些HTML標(biāo)記符和專門的關(guān)鍵詞。使用Javadoc 注釋的好處是編寫的注釋可以被自動(dòng)轉(zhuǎn)為在線文檔，省去了單獨(dú)編寫程序文檔的麻煩。?
例如：

/**?
* This is an example of?
* Javadoc?
*?
* @author darchon?
* @version 0.1, 10/11/2002?
*/

在每個(gè)程序的最開始部分，一般都用Javadoc注釋對(duì)程序的總體描述以及版權(quán)信息，之后在主程序中可以為每個(gè)類、接口、方法、字段添加 Javadoc注釋，每個(gè)注釋的開頭部分先用一句話概括該類、接口、方法、字段所完成的功能，這句話應(yīng)單獨(dú)占據(jù)一行以突出其概括作用，在這句話后面可以跟隨更加詳細(xì)的描述段落。在描述性段落之后還可以跟隨一些以Javadoc注釋標(biāo)簽開頭的特殊段落，例如上面例子中的@auther和@version，這些段落將在生成文檔中以特定方式顯示。

變量和常量命名

變量命名的方法采用匈牙利命名法，基本結(jié)構(gòu)為scope_typeVariableName，它使用3字符前綴來表示數(shù)據(jù)類型，3個(gè)字符的前綴必須小寫，前綴后面是由表意性強(qiáng)的一個(gè)單詞或多個(gè)單詞組成的名字，而且每個(gè)單詞的首寫字母大寫，其它字母小寫，這樣保證了對(duì)變量名能夠進(jìn)行正確的斷句。例如，定義一個(gè)整形變量，用來記錄文檔數(shù)量：intDocCount，其中int表明數(shù)據(jù)類型，后面為表意的英文名，每個(gè)單詞首字母大寫。這樣，在一個(gè)變量名就可以反映出變量類型和變量所存儲(chǔ)的值的意義兩方面內(nèi)容，這使得代碼語句可讀性強(qiáng)、更加容易理解。byte、int、char、long、float、 double、boolean和short。

變量類型和首字母對(duì)照關(guān)系如下表：

數(shù)據(jù)類型/對(duì)象類型 / 變量前綴 / 備注

byte bye?
char chr?
float flt?
boolean bln 做布爾變量時(shí)，使用bln?
Integer/int int?
String str?
Single sng?
short sht?
Long/long lng?
Double/double dbl?
Currency cur?
Variant bln astr obj vnt 做布爾變量用時(shí)，用bln，做字符串?dāng)?shù)組用時(shí)，用astr，做為對(duì)象使用時(shí)，用obj，不確定時(shí)，用vnt。

對(duì)于數(shù)組，在數(shù)據(jù)類型的前綴前再增加一個(gè)a，例如字符串?dāng)?shù)組為astr。對(duì)于在多個(gè)函數(shù)內(nèi)都要使用的全局變量，在前面再增加“g_”。例如一個(gè)全局的字符串變量：g_strUserInfo。

在變量命名時(shí)要注意以下幾點(diǎn)：

· 選擇有意義的名字，注意每個(gè)單詞首字母要大寫。

· 在一段函數(shù)中不使用同一個(gè)變量表示前后意義不同的兩個(gè)數(shù)值。

· i、j、k等只作為小型循環(huán)的循環(huán)索引變量。

· 避免用Flag來命名狀態(tài)變量。

· 用Is來命名邏輯變量，如：blnFileIsFound。通過這種給布爾變量肯定形式的命名方式，使得其它開發(fā)人員能夠更為清楚的理解布爾變量所代表的意義。

· 如果需要的話，在變量最后附加計(jì)算限定詞，如：curSalesSum。

· 命名不相包含，curSales和curSalesSum。

· Static Final 變量的名字應(yīng)該都大寫，并且指出完整含義。

· 如果需要對(duì)變量名進(jìn)行縮寫時(shí)，一定要注意整個(gè)代碼中縮寫規(guī)則的一致性。例如，如果在代碼的某些區(qū)域中使用intCnt，而在另一些區(qū)域中又使用intCount，就會(huì)給代碼增加不必要的復(fù)雜性。建議變量名中盡量不要出現(xiàn)縮寫。

· 通過在結(jié)尾處放置一個(gè)量詞，就可創(chuàng)建更加統(tǒng)一的變量，它們更容易理解，也更容易搜索。例如，請(qǐng)使用 strCustomerFirst和strCustomerLast，而不要使用strFirstCustomer和strLastCustomer。常用的量詞后綴有：First（一組變量中的第一個(gè)）、Last（一組變量中的最后一個(gè)）、Next（一組變量中的下一個(gè)變量）、Prev（一組變量中的上一個(gè)）、Cur（一組變量中的當(dāng)前變量）。

· 為每個(gè)變量選擇最佳的數(shù)據(jù)類型，這樣即能減少對(duì)內(nèi)存的需求量，加快代碼的執(zhí)行速度，又會(huì)降低出錯(cuò)的可能性。用于變量的數(shù)據(jù)類型可能會(huì)影響該變量進(jìn)行計(jì)算所產(chǎn)生的結(jié)果。在這種情況下，編譯器不會(huì)產(chǎn)生運(yùn)行期錯(cuò)誤，它只是迫使該值符合數(shù)據(jù)類型的要求。這類問題極難查找。

· 盡量縮小變量的作用域。如果變量的作用域大于它應(yīng)有的范圍，變量可繼續(xù)存在，并且在不再需要該變量后的很長時(shí)間內(nèi)仍然占用資源。它們的主要問題是，任何類中的任何方法都能對(duì)它們進(jìn)行修改，并且很難跟蹤究竟是何處進(jìn)行修改的。占用資源是作用域涉及的一個(gè)重要問題。對(duì)變量來說，盡量縮小作用域?qū)?huì)對(duì)應(yīng)用程序的可靠性產(chǎn)生巨大的影響。

關(guān)于常量的命名方法，在JAVA代碼中，無論什么時(shí)候，均提倡應(yīng)用常量取代數(shù)字、固定字符串。也就是說，程序中除0，1以外，盡量不應(yīng)該出現(xiàn)其他數(shù)字。常量可以集中在程序開始部分定義或者更寬的作用域內(nèi)，名字應(yīng)該都使用大寫字母，并且指出該常量完整含義。如果一個(gè)常量名稱由多個(gè)單詞組成，則應(yīng)該用下劃線“_”來分割這些單詞如：NUM_DAYS_IN_WEEK、MAX_VALUE。

資料來源于網(wǎng)絡(luò)

參考：

http://blog.csdn.net/faithpassion/article/details/38494443

http://blog.csdn.net/mr_li13/article/details/50286145

轉(zhuǎn)載于:https://www.cnblogs.com/binglong180/p/7849802.html

總結(jié)

以上是生活随笔為你收集整理的java J2EE 分层设计思想及各个文件命名规范的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。

上一篇：香港服务器使用CDN加速对网站有什么好处
下一篇： root大师一直卡在99怎么回事