efrei m1 jakartaee projet
1.0.0
การแข่งขัน Rolland Garos เป็นการแข่งขันเทนนิสนานาชาติ
พัฒนาการจัดการเว็บของการแข่งขันในการแข่งขัน Rolland Garos
บทบาทการทำงานของโครงการแอปพลิเคชันควรทำให้สามารถวางแผนการแข่งขันและวางแผนผู้เล่นคนไหนที่จะเข้าร่วมซึ่งผู้ตัดสินจะดูแลมัน จากนั้นคุณจะต้องสามารถแจ้งผลลัพธ์ของการแข่งขัน (คะแนนของแต่ละทีม) ผู้เข้าชมควรจะสามารถปรึกษาผลการแข่งขันที่เสร็จสิ้นได้
เมื่อดำเนินโครงการของเราเราได้ตั้งสมมติฐานหลายประการเกี่ยวกับการดำเนินการที่เราจินตนาการไว้สำหรับแอปพลิเคชันของเราและเพื่อรับประกันความสอดคล้องของหลัง:
สมมติฐาน 1:
ผู้จัดงานกำหนดตัวเองหากการแข่งขันสองครั้งเป็นแมตช์ชายหญิงหรือผสมเมื่อเขาทำคะแนนผู้เล่นในการแข่งขัน กล่าวคือถ้าเขาทำคะแนนในการแข่งขันสองครั้งชายและหญิงในทีมเดียวกันการแข่งขันจะถูกผสม สำหรับการแข่งขันง่าย ๆ มันเป็นไปไม่ได้ที่ผู้ชายจะเผชิญหน้ากับผู้หญิง แต่เขาไม่ได้ห้ามสำหรับสองเท่าที่ทีมของชายสองคนเผชิญหน้ากับทีมของผู้หญิงสองคน
สมมติฐาน 2:
เรามีแอปพลิเคชั่นเดียวสำหรับนักข่าวและผู้จัดงานและไม่ใช่แอปพลิเคชันที่แยกกันสองใบ ดังนั้นเราจึงมีโฮมเพจรวมถึงหน้าเว็บที่ช่วยให้คุณเห็นการแข่งขันเสร็จสิ้นและการกระทำอื่น ๆ (เช่นการเพิ่มผู้เล่นการวางแผนการแข่งขัน ฯลฯ ) สามารถเข้าถึงได้หลังจากการเชื่อมต่อ (เพื่อหาข้อมูลเพิ่มเติมเกี่ยวกับความปลอดภัยที่ใช้อ้างถึงส่วนความปลอดภัยของรายงาน)
สมมติฐาน 3:
เราตั้งสมมติฐานว่าการแข่งขันอาจใช้เวลาสูงสุด 4 ชั่วโมง เราได้เพิ่มคุณสมบัติที่ตรวจสอบว่าหลักสูตรฟรีก่อนที่เราจะเลือกได้สำหรับการแข่งขันใหม่ ดังนั้นเราจึงสามารถตรวจสอบให้แน่ใจว่าไม่สามารถเล่นเกมที่แตกต่างกันสองเกมในเวลาเดียวกันในหลักสูตรเดียวกัน ระยะเวลาสูงสุด 4 ชั่วโมงช่วยให้เราสามารถ จำกัด เพื่อให้สามารถเลือกหลักสูตรได้แม้ว่าจะมีการวางแผนการแข่งขัน แต่ยังไม่เสร็จ 4 ชั่วโมงก่อนเริ่มการแข่งขันใหม่
เพื่อดำเนินโครงการนี้เราได้จัดระเบียบตัวเองโดยใช้วิธี Agile
ในช่วงเริ่มต้นของโครงการเราเขียนบัญชีผู้ใช้ของแอปพลิเคชันต่อไปนี้:
สิ่งนี้สอดคล้องกับไดอะแกรมกรณีการใช้งานต่อไปนี้:
จากนั้นเราแบ่งเรื่องราวผู้ใช้เหล่านี้ออกเป็นงานพัฒนา
แต่ละเซสชั่นสอดคล้องกับการวิ่ง: เราทำการประชุมในช่วงเริ่มต้นของเซสชันเพื่อพิจารณาว่างานใดควรเป็นส่วนหนึ่งของโครงการ เพื่ออำนวยความสะดวกในการทำงานเราใช้เครื่องมือการจัดการโครงการที่รวมเข้ากับ GitHub: ร้านค้าเสื้อสเวตเตอร์คำขอและตาราง Kanban
งานถูกแสดงโดยผลลัพธ์ซึ่งสามารถมอบหมายให้ผู้ทำงานร่วมกัน ความคืบหน้าของงานตามมาด้วยการมีร้านค้าบนโต๊ะ Kanban เมื่อพนักงานทำงานเสร็จพวกเขาสร้างเสื้อสเวตเตอร์คำขอที่เกี่ยวข้องและส่งไปเพื่อตรวจสอบรหัส
เวิร์กโฟลว์มีดังนี้:
JSTL: ส่วนประกอบของแพลตฟอร์ม JEE เพื่อขยายข้อกำหนด JSP โดยการเพิ่มไลบรารีบีคอนสำหรับงานปัจจุบันเช่นการทำงานเกี่ยวกับทัณฑ์บนลูปและความเป็นสากล
MariaDB : Implémentation Open Source du Système de Gestion de
Base de Données Relationnel MySQL.
จาการ์ตา: ข้อกำหนดโอเพ่นซอร์สของ Java EE เราใช้ JSP โดยเฉพาะคอนเทนเนอร์ servlet, EJB และ JPA
Bootstrap est un framework CSS permettant de facilement implémenter des styles
prédéfinis
WildFly (เดิมชื่อ JBOSS) เป็นเซิร์ฟเวอร์แอปพลิเคชันโอเพนซอร์สที่ใช้ข้อมูลจำเพาะ Java EE / JAKARTA EE
EJB / Enterprise JavaBeans est une API de composants logiciels coté serveur
permettant d’encapsuler la logique métier des applications d’entreprise.
JPA (ข้อมูลจำเพาะ) / hibernate (การใช้งาน) เป็น ORM ซึ่งช่วยให้คุณสามารถทำให้เป็นอนุกรมและ dearialize java (เอนทิตี EJB) ในระบบการจัดการฐานข้อมูลเชิงสัมพันธ์
เราใช้สถาปัตยกรรม“ สถาปัตยกรรมที่สะอาด” ที่เรียกว่าสถาปัตยกรรม“ หัวหอม” ซึ่งประกอบด้วยเลเยอร์ที่แตกต่างกันแยกจากกันโดยสัญญาบริการที่อธิบายโดยอินเทอร์เฟซ เมื่อคำขอมาถึงจะถูกประมวลผลครั้งแรกโดยคอนโทรลเลอร์เพื่อสร้างวัตถุจากข้อมูลจากนั้นจะผ่านเลเยอร์บริการซึ่งมีตรรกะทางธุรกิจ เลเยอร์บริการเรียกใช้เลเยอร์ใหม่ซึ่งมีการโต้ตอบกับฐานข้อมูล เลเยอร์ใหม่ใช้คลาสของเอนทิตีของโมเดลข้อมูล
ในแอปพลิเคชันของเราแต่ละเลเยอร์สอดคล้องกับส่วนประกอบต่อไปนี้:
เราใช้การเขียนโปรแกรมอินเทอร์เฟซรวมถึงกลไกการฉีดพึ่งพาที่ได้รับอนุญาตจาก บริษัท ถั่วชวาเพื่อให้มีการมีเพศสัมพันธ์ต่ำระหว่างส่วนประกอบแอปพลิเคชัน
เราระมัดระวังไม่ให้เก็บรหัสผ่านผู้ใช้อย่างชัดเจนในฐานข้อมูล ดังนั้นหากถูกแฮ็กหลังผู้โจมตีจะไม่สามารถเข้าถึงรหัสผ่านได้ เราเลือกที่จะสับรหัสผ่านด้วยอัลกอริทึมแฮชบิคปิ้งเค็มเพราะเป็นมาตรฐานในเรื่อง ในการทำเช่นนี้เรานำเข้าห้องสมุด JBCrypt ในโครงการของเรา (ผ่าน Maven) ซึ่งใช้อัลกอริทึมใน Java
ในแอปพลิเคชันถนนส่วนใหญ่ควรเข้าถึงได้โดยผู้ใช้ที่ได้รับการรับรองความถูกต้องเท่านั้น ดังนั้นเราจึงตั้งค่าหน้าตรวจสอบสิทธิ์เพื่อรับรองความถูกต้องของผู้ใช้ เราใช้เซสชัน HTTP เพื่อจัดเก็บโปรไฟล์ผู้ใช้ที่ได้รับการรับรองความถูกต้อง
เพื่อให้ผู้ใช้บนถนนที่ได้รับการป้องกันเราได้ตั้งค่าตัวกรอง HTTP ที่ได้รับอนุญาตซึ่งตรวจสอบว่าเซสชัน HTTP ปัจจุบันมีโปรไฟล์ผู้ใช้ที่ได้รับการรับรองความถูกต้องหรือไม่ ถ้าเป็นเช่นนั้นตัวกรองอนุญาตให้ผู้ใช้มิฉะนั้นจะเปลี่ยนเส้นทางไปยังหน้าการเชื่อมต่อ
เราเริ่มดำเนินการตามโครงการโดยการสร้างคลาสธุรกิจ (หน่วยงานของแพ็คเกจโครงการของเรา) ตามที่เราได้กำหนดไว้ในระหว่างการสร้างแบบจำลอง จากนั้นเราสร้างคลาสและอินเทอร์เฟซทำให้เราสามารถเข้าถึงฐานข้อมูล (แพ็คเกจใหม่) ในที่สุดเราได้ใช้ความเป็นไปได้ในการระบุแอปพลิเคชันของเราทั้งหมดเข้าด้วยกันเพื่อที่จะตกลงกันในข้อตกลงบางอย่างเพื่อให้โครงการของเราสอดคล้องกัน เมื่อขั้นตอนเหล่านี้เสร็จสมบูรณ์เราจะแบ่งงานโดยให้เรื่องราวของผู้ใช้จำนวนหนึ่งที่ต้องทำทุกคนทำงานได้เสร็จสิ้นจนกว่าเรื่องราวของผู้ใช้ทั้งหมดจะดำเนินการ
เรื่องราวของผู้ใช้ส่วนใหญ่สร้างขึ้นได้ง่ายยกเว้นเรื่องราวของผู้ใช้: เตรียมการแข่งขัน ในระหว่างการสร้างแบบจำลองแอปพลิเคชันครั้งแรกของเราเราได้แสดงลิงก์“ หลายคน” ที่เชื่อมต่อผู้เล่นเข้ากับการแข่งขันไม่ดีเราไม่ได้หลงใหลในชั้นเรียนที่เป็นตัวแทนของทีม (คลาสการมีส่วนร่วมในโครงการของเรา) ดังนั้นเมื่อเราพยายามเพิ่มผู้เล่นในเกมในระหว่างขั้นตอนการเตรียมการมีการเปิดตัวข้อยกเว้นและการเตรียมการจับคู่ก็ไม่ได้ทำ หลังจากดูรายละเอียดเพิ่มเติมเกี่ยวกับการทำงานของความสัมพันธ์“ หลายคนถึงหลายคน” เราตระหนักว่ามันเป็นไปไม่ได้ที่จะสร้างความสัมพันธ์สองประเภทนี้ระหว่างสองคลาสเดียวกัน (ที่นี่สองความสัมพันธ์ที่เชื่อมต่อผู้เล่นกับเกมเพราะมีสองทีมเสมอ) โดยไม่ต้องผ่านชั้นเรียนกลาง (ที่นี่การมีส่วนร่วม) ดังนั้นเราจึงต้องปรับเปลี่ยนแผนภาพคลาสของเราเพื่อให้สามารถจำลองการใช้งานใหม่ของเราได้อย่างถูกต้องรวมถึงปรับเปลี่ยนการแข่งขันและคลาสธุรกิจของผู้เล่นและเพิ่มคลาสการมีส่วนร่วมเพื่อให้แอปพลิเคชันของเราทำงานได้อย่างสมบูรณ์แบบ
ปัญหาที่สองที่พบไม่ได้เกี่ยวข้องกับเรื่องราวของผู้ใช้โดยเฉพาะ แต่เป็นปัญหาการเข้ารหัสข้อมูล หลังจากจบเรื่องราวของผู้ใช้ทั้งหมดของเราในระหว่างการทดสอบต่าง ๆ ของเราและในระหว่างการปรับปรุงของเราเราสังเกตเห็นว่าสำเนียงซึ่งได้รับการสนับสนุนโดย UTF8 โดยปกติจะไม่ถูกเก็บไว้ในฐานข้อมูลอย่างเหมาะสม อันที่จริงอักขระสำเนียงทั้งหมดในฐานถูกแทนที่ในรูปแบบอื่น หลังจากดูอินเทอร์เน็ตเราเข้าใจว่าปัญหามาจาก WildFly และเพื่อแก้ปัญหาเราจึงต้องเปลี่ยนการเข้ารหัสของคอนเทนเนอร์ servlet ในการกำหนดค่า WildFly ในการทำเช่นนี้เราต้องไปที่การกำหนดค่า WildFly และแก้ไขการตั้งค่าการเข้ารหัสเริ่มต้นของคอนเทนเนอร์ Servlet โดย UTF-8
นอกจากนี้เรายังพบปัญหาเกี่ยวกับการจัดการรูปแบบวันที่ เราใช้ประเภท LocalDate (API วันที่ล่าสุดใน Java) ในชั้นธุรกิจของเราเพื่อจัดเก็บวันที่กำหนดเวลาของการแข่งขันเช่น ตอนนี้ JSTL ไม่มีฟังก์ชั่นในการจัดรูปแบบวันที่ประเภทนี้เนื่องจากยังคงใช้ API วันที่ Java เก่า ดังนั้นเราจึงต้องทำการจัดรูปแบบมือในหน้า JSP ซึ่งแสดงวันที่ (คุณสามารถไปดูการจัดรูปแบบนี้ในหน้า consolmatches.jsp เป็นต้น)
เมื่อความยากลำบากเหล่านี้เอาชนะได้เราก็สามารถมุ่งเน้นไปที่การปรับปรุงแอปพลิเคชันของเราและปรับข้อบกพร่องเล็กน้อย
ในระหว่างโครงการนี้เราได้รับการแนะนำให้รู้จักกับการพัฒนาแอปพลิเคชันทางธุรกิจกับจาการ์ตา EE แม้ว่าบางส่วนของพวกเขามีประสบการณ์บนเซิร์ฟเวอร์ทางฝั่งเซิร์ฟเวอร์ แต่โครงการนี้มีโอกาสที่จะทำให้เรามีมาตรฐานการพัฒนาแพลตฟอร์มที่เหมาะสม
เราสามารถตั้งค่าทักษะเกี่ยวกับเทคโนโลยี JPA ของ ORM ซึ่งมี API ที่อุดมไปด้วยมีพลังมาก กลไกบางอย่างเช่นความสัมพันธ์ "หลายต่อหลายคน" ทำให้เรามีปัญหา แต่เราต้องเอาชนะพวกเขา
ในที่สุดแง่มุมความร่วมมือของโครงการนี้เป็นหนึ่งในจุดแข็งของมัน อันที่จริงแรงจูงใจร่วมกันเป็นเครื่องมือที่ทรงพลังที่ช่วยให้คุณสามารถเอาชนะความยากลำบากได้ทุกประเภท สิ่งนี้ยังทำให้เรามีโอกาสที่จะใช้ทักษะการจัดการโครงการ Agile ที่ได้รับในโมดูลอื่น ๆ เพื่อทำงานร่วมกันอย่างมีประสิทธิภาพมากที่สุด
