โครงสร้างโฟลเดอร์แอปพลิเคชันเว็บ Java


18

ในฐานะผู้เริ่มต้นสู่ J2EE ฉันเพิ่งเริ่มพัฒนาโครงการของตัวเองตั้งแต่เริ่มต้นโดยใช้ Core ของ J2EE: Servlets & Jsps

ฉันไม่สามารถประเมินว่าโครงสร้างโฟลเดอร์โครงการของฉันถูกต้องหรือไม่ นี่คือโครงสร้างโฟลเดอร์โครงการของฉัน ป้อนคำอธิบายรูปภาพที่นี่

ก่อนที่จะถามคำถามฉันยอมรับว่าฉันไม่สามารถตอบได้หรือไม่พิสูจน์ว่ามีคนถามฉันทำไมโครงสร้างโฟลเดอร์ประเภทนี้ คำถาม: มันเป็นสัญญาณที่ดีหรือไม่ที่จะนำ jsps ของฉันออกไปนอกเว็บอิน ถ้าไม่เป็นเช่นนั้นทำไม ถ้าใช่ทำไม

มีแบบแผนโครงสร้างโฟลเดอร์มาตรฐานสำหรับเว็บแอปพลิเคชัน J2EE หรือไม่ฉันรู้ว่า maven ได้นำมาตรฐานบางอย่างมาใช้ แต่ยังคงเราสามารถปรับแต่งได้ตามความต้องการที่ฉันเชื่อ

ฉันทำ googling ไปเล็กน้อยแล้วพบข้ออ้างอิงสองข้อ 1 2

ในคำตอบนั้นไม่ได้อยู่ในหน้าเดียวกันซึ่งฉันไม่สามารถสรุปได้

อะไรคือประเด็นที่ต้องพิจารณาในขณะที่จัดโครงสร้างของโฟลเดอร์สำหรับเว็บแอปพลิเคชัน J2EE ที่สำคัญคือ Jsps เนื้อหาแบบคงที่ควรเข้าที่ & ทำไม



ฉันขอแนะนำให้คุณศึกษาทฤษฎี MVC - บทความวิกิพีเดียมีแหล่งข้อมูลที่ดีเยี่ยม หากคุณต้องการทดสอบกับ MVC ใน Java webapp Stripesเป็นเฟรมเวิร์คที่มีน้ำหนักเบาที่ยอดเยี่ยมที่สามารถให้ภาพรวมของสถาปัตยกรรมแก่คุณ
Michael K

1
นี่คือการปฏิบัติที่เฉพาะเจาะจงมากขึ้นว่า MVC ทำงานใน webapps
Michael K

คำตอบ:


7

โครงสร้างมาตรฐานสำหรับไฟล์ WAR คือ:

/META-INF
   Standard jar stuff like manifest.xml
/WEB-INF
  web.xml
  /classes
    /com...etc.
  /lib

Maven สร้างนี้สำหรับคุณโดยใช้ src ของคุณ / / java หลักทรัพยากร webapp และการอ้างอิงของคุณ (วางไว้ใน / lib) ในMaven-webapp ปลั๊กอินแต่ว่าการดำเนินการของ สิ่งสำคัญที่ต้องตระหนักคือทุกสิ่งที่คุณใส่ใน WEB-INF นั้นไม่สามารถเข้าถึงได้จากภายนอกในขณะที่ทุกสิ่งในไดเรกทอรีรากของสงครามเป็นแบบสาธารณะ

โดยทั่วไปคุณไม่ต้องการใส่อะไรลงในรูทมากนักเนื่องจากคุณต้องการให้แอปพลิเคชันของคุณจัดการการเข้าถึงทั้งหมดโดยใช้เซิร์ฟเล็ตและตัวกรองที่คุณกำหนดใน web.xml เป็นเรื่องปกติที่จะเห็น index.html (หรือ. jsp) ในรูทที่เปลี่ยนเส้นทางไปยังเซิร์ฟเล็ตตัวอย่างเช่นแอ็คชันStruts

การใช้ MVC ทั่วไปเช่น Stripes หรือ Struts แนะนำให้ต่อต้านการเข้าถึง JSP ของผู้ใช้โดยตรงโดยเลือกให้ JSP เป็นแบบดูอย่างเดียว พวกเขาแนะนำให้สร้างตัวควบคุมที่ส่งต่อไปยัง JSP หลังจากประมวลผลคำขอและ JSPs จะแสดงผลลัพธ์เพียงอย่างเดียว ตัวอย่างเช่นการส่งแบบฟอร์มไปยัง/loginจะเรียกใช้การกระทำที่ประมวลผลคำขอเข้าสู่ระบบสร้างเซสชันของผู้ใช้และส่งต่อผู้ใช้ไปยังมุมมองเข้าสู่ระบบของโฮมเพจ JSP


5

คำตอบปกติของ "สิ่งที่ถูกต้องคืออะไร" หรือ "นี่เป็นวิธีที่ถูกต้องหรือไม่" คือ ..... มันขึ้นอยู่กับ

สิ่งที่ฉันทำได้คือบอกข้อดีและข้อเสียของความคิดเฉพาะ สิ่งที่ตามมาคือความคิดเห็นของฉัน 100% ฉันไม่รู้ข้อกำหนดหรือกฎเกณฑ์เฉพาะใด ๆ ฉันแน่ใจว่าบางคนจะไม่เห็นด้วยกับฉัน

ของ JSP

มาทำงานกันว่าจะใส่ JSP ใน WEB-INF หรือไม่

ข้อดีของการวาง JSP ไว้ใน WEB-INF:

  • คุณควบคุมวิธีการดำเนินการของ JSP หากคุณต้องการให้ JSP เป็นพารามิเตอร์และใช้งานได้อีกครั้ง (ซึ่งยากมากกับ JSP ต่อไป) คุณสามารถใส่ไว้ใน WEB-INF และใช้ servlet หรือ Struts action controller หรือตัวควบคุมด้านหน้าอื่น ๆ เพื่อทำการประมวลผลล่วงหน้า จากนั้นผ่านการควบคุมไปยัง JSP ผ่านในบริบทของสภาพแวดล้อมที่เหมาะสม (เช่นแอตทริบิวต์การร้องขอการตรวจสอบความปลอดภัยใด ๆ การสุขาภิบาลพารามิเตอร์ ฯลฯ )
  • คุณสามารถเขียนโปรแกรมหรือแม้กระทั่งที่ไฟร์วอลล์หรือการร้องขอ HTTP ระดับบล็อก IDS ไปที่ * .jsp เพื่อลดโอกาสที่บางคนอัพโหลด JSP ไปยังรูทเว็บจากนั้นจะสามารถเรียกใช้โค้ดเป็นเว็บเซิร์ฟเวอร์ได้ พวกเขาจะต้องเขียน JSP ที่มีอยู่มากเกินไป ไม่ได้รับความปลอดภัยมากนัก แต่มันทำให้การประนีประนอมหนักขึ้นเล็กน้อย
  • บังคับใช้นิสัยที่ดีเช่น MVC ตัวควบคุมด้านหน้าฟิลเตอร์ servlet การฉีดพึ่งพาเป็นต้นเมื่อเทียบกับ JSP ที่ชั่วร้ายขนาดใหญ่ที่ทำงานทั้งหมดเองและยากที่จะอ่าน / ดูแล

ข้อเสียของการวาง JSP ใน WEB-INF:

  • คุณไม่สามารถเข้าถึงหน้านี้ได้โดยตรงแม้ว่าจะเป็นหน้าแบบสแตนด์อโลนที่เรียบง่ายซึ่งไม่ต้องการการประมวลผลล่วงหน้า นี่เป็นเพราะไฟล์ภายใต้ / WEB-INF ไม่สามารถใช้งานได้โดยภาชนะเซิร์ฟเล็ต

ไฟล์คงที่

ในแง่ของไฟล์แบบคงที่ล้วนๆเช่น HTML, รูปภาพ, สไตล์ชีต, จาวาสคริปต์ ฯลฯ วางไฟล์เหล่านั้นไว้ใต้เว็บรูท (my_app ในกรณีของคุณ) แต่ไม่ใช่ / WEB-INF (เพราะไม่สามารถเข้าถึงได้)

เค้าโครงโดยรวม

สำหรับเค้าโครงไดเรกทอรีโดยรวมนั้นขึ้นอยู่กับกระบวนการสร้างของคุณ ฉันชอบจัดเก็บทุกอย่างภายใต้ "src" หรือ "แหล่งที่มา" เพราะทำให้ชัดเจนว่าไฟล์ใดที่ถูกสร้างขึ้นโดยการสร้างและเป็นแหล่งที่บริสุทธิ์ mainให้คุณแยกรหัสการทดสอบเช่นคลาส junit จากซอร์สโค้ดหลักของคุณซึ่งก็ดีเหมือนกัน แต่ถ้าคุณไม่มีการทดสอบหน่วย (โอ้ไม่!) มันก็เป็นความแตกต่างที่ไร้ความหมาย

ในทางตรงกันข้ามหากคุณไม่ได้จัดการรูทเว็บในระหว่างการสร้าง (เช่นถ้ามันเป็นไฟล์ JSP และสแตติกทั้งหมด) บางทีคุณอาจเก็บมันไว้ที่ระดับบนสุดเช่น/webrootหรือ/deployคัดลอกไฟล์ตามที่ต้องการเช่น ไฟล์. class หรือ. jar มันเป็นนิสัยของมนุษย์ (โดยเฉพาะนักพัฒนา) เพื่อจัดระเบียบมากเกินไป สัญญาณที่ดีของการจัดระเบียบมากคือการมีโฟลเดอร์จำนวนมากโดยมีโฟลเดอร์ย่อยเพียงโฟลเดอร์เดียว

สิ่งที่คุณแสดง

คุณระบุว่าคุณกำลังติดตามการประชุมที่กำหนดโดย maven ดังนั้นหากคุณกำลังใช้ maven อยู่แล้วเพียงแค่ยึดตามเค้าโครงนั้น ไม่มีอะไรผิดปกติกับเค้าโครงที่คุณอธิบาย


1

src / main / webapp ของคุณทำให้ฉันนึกถึงโครงการ maven แน่นอน สิ่งไหนดี.

สำหรับ my_app / jsps ฉันไม่แน่ใจ นักพัฒนามักจะปล่อย jsp ไว้ในโฟลเดอร์ webapp หรือหากคุณต้องการทำ url-map เล็กน้อยในไดเรกทอรี webapp / jsp

!คำเตือน! : คุณไม่ควรใส่ไฟล์ jsp ใน web-inf WEB-INF ของคุณควรมีไฟล์ xml เพื่อกำหนดค่าเว็บไซต์ของคุณเท่านั้น จำไว้ว่า jsp ของคุณเป็นเว็บเพจหรือบางส่วนของเว็บเพจ

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


src / main / webapp มีไฟล์โครงร่างของ WAR มาตรฐานและถูกอ่านโดยmaven-war-pluginเมื่อรวบรวม Java webapp
Michael K

1
ไม่มีเหตุผลใดที่คุณไม่ควรใส่ JSP ใน WEB-INF ตราบใดที่คุณกำหนดค่าเซิร์ฟเล็ตใน web.xml ของคุณซึ่งจะส่งต่อไปในที่สุด นี่เป็นวิธีมาตรฐานในการติดตั้งแอป Struts - คำขอทั้งหมดต้องผ่านเซิร์ฟเล็ต Struts ซึ่งแม็พกับการดำเนินการและจากนั้นไปที่ JSP
Michael K

ฉันเห็นด้วยกับความจริงที่ว่า jsp ไม่ควรเข้าถึงได้โดยตรงและป้องกันไม่ให้ถือว่าเป็นแนวทางปฏิบัติที่ดี แต่มีวิธีอื่นที่จะทำเช่นนั้น
Brice Ruppen

1

ผมเห็นด้วยกับไบรส์ ฉันเริ่มต้นด้วย J2EE แต่ฉันคิดว่ามันจะทำงานได้ดีขึ้นและชัดเจนในตอนแรก

โฟลเดอร์รูทคือ WEBAPP และคุณควรทำให้โครงสร้างเว็บของคุณคิดว่าหน้าเว็บส่วนใหญ่จะค้นหาที่นั่น ถ้าไม่เมื่อหน้าสื่อสารระหว่างพวกเขาอาจคุณไม่สามารถจัดการความสัมพันธ์ของไฟล์โดยไม่มีข้อผิดพลาด


1

อันที่จริงการประยุกต์ใช้ WAR WEB-INF/web.xmlสามารถสร้างได้โดยไม่ต้อง เป็นไปได้ที่จะสร้างแอปพลิเคชัน WAR ด้วยคลาส Java ภายในเท่านั้น

แหล่งที่มา: องค์ประกอบอธิบายการปรับใช้ web.xml

ด้วยหมายเหตุประกอบ Java EE ตัวให้คำอธิบายถึงการปรับใช้ web.xml มาตรฐานเป็นทางเลือก ตามข้อกำหนดคุณสมบัติเซิร์ฟเล็ต 3.0 ที่http://jcp.org/en/jsr/detail?id=315คำอธิบายประกอบสามารถกำหนดได้บนคอมโพเนนต์ของเว็บบางตัวเช่น servlets ตัวกรองตัวรับฟังและตัวจัดการแท็ก

ทุกวันนี้มีความเป็นไปได้ที่จะสร้าง WAR มากกว่าดูเหมือน JAR ที่มี.warส่วนขยาย :)

ตอบคำถามของคุณโครงสร้าง WAR ขึ้นอยู่กับความต้องการของคุณ

http://en.wikipedia.org/wiki/WAR_(Sun_file_format)

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.