โครงสร้างแพ็คเกจสำหรับโปรเจ็กต์ Java?

116

แนวทางปฏิบัติที่ดีที่สุดในการตั้งค่าโครงสร้างแพ็คเกจใน Java Web Application คืออะไร

คุณจะตั้งค่า src รหัสทดสอบหน่วย ฯลฯ ของคุณอย่างไร

java packages

95

คุณสามารถทำตาม Maven ของรูปแบบโครงการมาตรฐาน คุณไม่จำเป็นต้องใช้ maven จริงๆ แต่มันจะทำให้การเปลี่ยนแปลงง่ายขึ้นในอนาคต (ถ้าจำเป็น) นอกจากนี้นักพัฒนาคนอื่น ๆ จะคุ้นเคยกับการดูเลย์เอาต์นั้นเนื่องจากโปรเจ็กต์โอเพนซอร์สจำนวนมากถูกจัดวางในลักษณะนี้

— johnstok
แหล่งที่มา

2

ฉันขอแนะนำให้ใช้เลย์เอาต์ของ Maven หากคุณมีทางเลือก เป็นโครงสร้างที่คิดมาอย่างดีซึ่งผ่านการทดสอบการต่อสู้และคุ้นเคยกับนักพัฒนาหลายคน

— Dov Wasserman

15

คุณสามารถใช้ oneliner นี้เพื่อสร้างเค้าโครงไดเรกทอรี: mkdir -p src / {main / {java, resources, filters, assembly, config, webapp}, test / {java, resources, filters}, site}

— Daniel Hepper

1

เค้าโครงโครงการมาตรฐานของ Maven น่าเกลียด ... : /

— Yousha Aleayoub

2

@YoushaAleayoub คุณไม่ต้องแต่งงานกับมัน

— Ashvin Sharma

59

มีทรัพยากรที่มีอยู่สองสามอย่างที่คุณอาจตรวจสอบได้:

สำหรับสิ่งที่คุ้มค่าแนวทางส่วนตัวของฉันเองที่ฉันมักจะใช้มีดังนี้:

เริ่มต้นด้วยโดเมนย้อนกลับเช่น "com.mycompany"
ใช้ชื่อผลิตภัณฑ์เช่น "myproduct" ในบางกรณีฉันมักจะมีแพ็คเกจทั่วไปที่ไม่ได้เป็นของผลิตภัณฑ์ใดผลิตภัณฑ์หนึ่ง สิ่งเหล่านี้จะถูกจัดหมวดหมู่ตามฟังก์ชันการทำงานของคลาสทั่วไปเหล่านี้เช่น "io" "util" "ui" เป็นต้น
หลังจากนี้จะกลายเป็นรูปแบบอิสระมากขึ้น โดยปกติฉันจะจัดกลุ่มตามโครงการพื้นที่การใช้งานการปรับใช้ ฯลฯ ตัวอย่างเช่นฉันอาจมี "project1", "project2", "ui", "client" เป็นต้น

อีกสองประเด็น:

เป็นเรื่องปกติในโครงการที่ฉันได้ทำเพื่อให้ชื่อแพ็คเกจไหลจากเอกสารการออกแบบ โดยปกติผลิตภัณฑ์จะถูกแยกออกเป็นส่วนของฟังก์ชันการทำงานหรือวัตถุประสงค์อยู่แล้ว
อย่าเครียดมากเกินไปกับการผลักดันฟังก์ชันการทำงานทั่วไปไปยังแพ็กเกจที่สูงขึ้นในทันที รอให้มีความต้องการในโปรเจ็กต์ผลิตภัณฑ์และอื่น ๆ จากนั้นทำการรีแฟคเตอร์
ดูการพึ่งพาระหว่างแพ็คเกจ มันไม่ได้เลวร้ายทั้งหมด แต่มันสามารถบ่งบอกถึงการมีเพศสัมพันธ์ที่แน่นหนาระหว่างสิ่งที่อาจเป็นหน่วยแยกต่างหาก มีเครื่องมือที่ช่วยให้คุณติดตามสิ่งนี้ได้

— lycono
แหล่งที่มา

2

ในกรณีโดเมนย้อนกลับ ("com.mycompany") โดยปกติแพ็กเกจ "com" จะว่างเปล่ายกเว้นแพ็กเกจย่อย "mycompany" หรือไม่

— Alex Parker

45

ฉันขอแนะนำให้สร้างโครงสร้างแพ็กเกจของคุณตามคุณลักษณะไม่ใช่ตามชั้นการนำไปใช้งาน การเขียนที่ดีเกี่ยวกับสิ่งนี้คือแนวทางปฏิบัติของ Java: แพ็กเกจตามคุณลักษณะไม่ใช่เลเยอร์

— นักวิเคราะห์ข้อมูล
แหล่งที่มา

2

ขอบคุณ นี่คือสิ่งที่ฉันต้องการเพื่อถ่ายทอดความคิดของฉันกับทีม

— Pranalee

8

และหากคุณต้องการเปลี่ยนฐานข้อมูล? มีให้เลือกเพียง 30 แพ็คเกจเท่านั้น ย้ายจาก SFTP ไปยังบริการเว็บไหม ต้องไปดูในสถานที่ต่างๆ 30 แห่งเท่านั้น ไม่ใช่แฟนแน่นอน

— SamuelKDavis

1

อีกตัวอย่างหนึ่งที่บรรจุภัณฑ์ตามชั้นมีประโยชน์: ถ้าคุณจัดลำดับคลาสเป็น JSON (เช่นด้วย gson) หากคลาสเหล่านั้นสับสน (เช่นโดย Proguard) (de) การทำให้เป็นอนุกรมจะล้มเหลว คุณต้องกำหนดค่า Proguard ไม่ให้สัมผัสกับคลาสดังกล่าว - เป็นวิธีที่ง่ายที่สุดเพียงระบุแพ็กเกจเดียวกับทั้งหมด

— jmuet

6

ฉันมักจะมีสิ่งต่อไปนี้:

bin (ไบนารี)
doc (เอกสาร)
inf (ข้อมูล)
lib (ไลบรารี)
res (ทรัพยากร)
src (ที่มา)
tst (ทดสอบ)

สิ่งเหล่านี้อาจถือว่าไม่ธรรมดา แต่ฉันคิดว่ามันเป็นวิธีที่ดีมากในการจัดระเบียบสิ่งต่างๆ

"สิ่งเหล่านี้อาจถือได้ว่าแหวกแนว" จริงๆแล้วพวกมันแหวกแนวและแย่มาก ๆ ...

— mahieddine

2

@mahieddine ทำไมคุณถึงมองว่าพวกเขาไม่ดี?

— Thomas Johannesmeyer

ไม่ใช่ฉันที่พูดแบบนั้น แต่นี่คือความคิดของฉัน: คลาสทดสอบของคุณเป็นซอร์สโค้ดดังนั้นไดเร็กทอรี "tst" (คนส่วนใหญ่ไม่ได้ย่อ test btw) ควรเป็นไดเร็กทอรีย่อยของ src (เช่น " src "กลายเป็น" src / main "และ" tst "กลายเป็น" src / test ") นอกจากนี้ "inf" ดูเหมือนว่าจะมีเนื้อหาที่อาจอยู่ใน "doc" ด้วย

— Nico Wawrzyniak

6

The way I usually organise is
- src
        - main
                - java
                - groovy
                - resources
        - test
                - java
                - groovy
- lib
- build
        - test 
                - reports
                - classes
- doc

— ราชา
แหล่งที่มา

3

วิธีที่ฉันมักจะมีลำดับชั้นของโฟลเดอร์ -

ชื่อโครงการ
- src
- ถัง
- การทดสอบ
- libs
- เอกสาร

— pdeva
แหล่งที่มา

1

อีกวิธีหนึ่งคือการแยก API บริการและเอนทิตีออกเป็นแพ็กเกจต่างๆ

— Deepak Patankar
แหล่งที่มา