วิศวกรรมภายในของ RAD Framework... ในฐานะนักพัฒนา PHP กับ Nooku

ทุกคนมีชุดเครื่องมือของตัวเอง ในฐานะนักพัฒนา PHP หนึ่งในรายการโปรดของฉันคือเฟรมเวิร์ก Rapid Application Development ที่เรียกว่า “Nooku” ตามคำพูดของกลุ่มพัฒนา: "Nooku เป็นชุดเครื่องมือการพัฒนาเว็บมากกว่าเฟรมเวิร์ก"

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

• การใช้งานเริ่มต้นของ MVC โดยสิ่งที่คุณต้องทำคือเขียนเลย์เอาต์ (นี่คือสิ่งที่ทำให้ฉันสนใจ)
• HMVC พร้อมใช้งานทันที
• รองรับรูปแบบเอาต์พุตต่างๆ เช่น JSON และ XML สำหรับข้อมูลทั้งหมดของคุณ (เช่น เปิดเผย API ของคุณในไม่กี่นาที)
• การใช้งานการดูแลระบบเริ่มต้นและส่วนหน้า

หัวใจสำคัญของ Nooku คือหลักการออกแบบ "องค์ประกอบเหนือการสืบทอด" (อันที่จริง เป็นแนวคิดแรกในหน้าแนะนำ Nooku ในบรรทัดเดียว: คุณควรตั้งเป้าที่จะเขียน (หรือเพิ่ม) การทำงานของวัตถุหลายชิ้นเพื่อสร้างบางส่วน ประเภทของอ็อบเจ็กต์คอมโพสิต แทนที่จะอาศัยคลาสย่อย

หลักการนี้ช่วยให้คุณเขียนโค้ดน้อยลงและมักจะนำไปสู่วิธีแก้ปัญหาที่สวยงาม แล้วจะส่งเสริมได้อย่างไร? ที่ระดับโค้ด ตัวอย่างที่ดีที่สุดมาจากการใช้ Mixins และตัวระบุทรัพยากร/บริการ มาดูกันเลย

The Mixin

ก่อน PHP 5.4 ภาษาไม่มีแนวคิดเรื่อง Traits โครงสร้างเหล่านี้เป็นโครงสร้างแบบคลาสที่เมื่อ 'ใช้' โดยอ็อบเจ็กต์ จะมีฟังก์ชันการทำงานบางประเภท (คล้ายกับการสืบทอดหลายรายการ) Nooku ได้แก้ปัญหานี้มาหลายปีแล้ว (ตั้งแต่ PHP 5.2) ด้วย Mixin .

Mixin ไม่เพียงแต่ช่วยให้คุณสามารถเขียนวัตถุร่วมกันได้ แต่ยังเพิ่มวิธีการของวัตถุผสมแต่ละรายการไปยังอินเทอร์เฟซของวัตถุผสม ดูเหมือนว่าวัตถุที่ใช้มิกซ์อินจะ 'สืบทอด' วิธีการแบบผสมของวัตถุ

 /** * Mixin an object * * When using mixin(), the calling object inherits the methods of the mixed * in objects, in a LIFO order. * * @param KMixinInterface $object An object that implements KMinxInterface * @return KObject */ public function mixin(KMixinInterface $object) { $methods = $object->getMixableMethods($this); foreach($methods as $method) { $this->_mixed_methods[$method] = $object; } // Set the mixer $object->setMixer($this); return $this; }

ออบเจ็กต์เกือบทั้งหมดใน Nooku มีความสามารถนี้เนื่องจากขยายคลาสพื้นฐาน KObject ที่กำหนดวิธีการมิกซ์อิน

คลาสหลักในสถาปัตยกรรมคอนโทรลเลอร์ของ Nooku ก็สืบเชื้อสายมาจาก KObject ด้วย ตัวควบคุมนามธรรมคือคลาส KControllerAbstract และจากการตรวจสอบ คุณจะเห็นว่าได้ใช้ประโยชน์จากความสามารถในการผสมในทันที เมื่อใดก็ตามที่สร้างอินสแตนซ์ของคลาสนี้ ฟังก์ชัน KMixinCommand และ KMixinBehavior จะถูกเพิ่มลงในอินเทอร์เฟซทันที ดังนั้น คอนโทรลเลอร์แต่ละตัวใน Nooku จึงประกอบด้วย Command Chain และฟังก์ชันการจัดการพฤติกรรมผ่านอ็อบเจ็กต์ที่เกี่ยวข้อง

กลับไปที่ตัวควบคุม Nooku: คลาส KMixinBehavior มีส่วนประกอบทั้งหมดเพื่อให้ KControllerAbstract โหลด Behaviors เฉพาะที่รันไทม์ได้ กลวิธีเชิงพฤติกรรมคือคลาสที่อธิบายกระบวนการหรือตรรกะที่สามารถแยกออกและใช้โดยคลาสอื่น (เช่น แก้ไขได้ สั่งได้) KMixinBehavior นั้นค่อนข้างเรียบง่ายและมีเพียงสี่วิธีเท่านั้น: getBehavior, hasBehavior, addBehavior และ getBehaviors และนั่นคือทั้งหมดที่เราต้องการให้วัตถุมีความสามารถในการจัดการและสรุปกลยุทธ์ด้านพฤติกรรมต่างๆ

ในทำนองเดียวกัน KMixinCommand มีเพียงสามวิธี: getCommandContext, getCommandChain, setCommandChain หากคุณไม่ได้คาดเดา วิธีการทั้งสามนี้จะทำให้ KControllerAbstract มีความสามารถในการนำชุดคำสั่งไปใช้ แต่ให้ทำได้ในขณะใช้งานจริง

คุณสามารถนึกถึงการผสมนี้เป็นการบวกเลขคณิตอย่างง่าย:

ให้อินเทอร์เฟซที่มีลักษณะดังนี้:

ตามคำจำกัดความ คลาสนามธรรมมีไว้เพื่อขยาย ดังนั้นด้วยความมหัศจรรย์ของการสืบทอดอ็อบเจ็กต์ทั้งหมดที่เป็นลูกหรืออินสแตนซ์ของ KControllerAbstract ยังได้รับความสามารถในการเพิ่มพฤติกรรมและสายคำสั่งที่รันไทม์

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

สองตัวอย่างนี้ใช้เพื่อสาธิตองค์ประกอบ พวกเขายังแสดงการสนับสนุนเฟรมเวิร์ก Nooku RAD สำหรับองค์ประกอบเพิ่มเติมที่เป็นแกนหลัก นี่เป็นข้อได้เปรียบที่สำคัญ วิธีการที่เพิ่มไปยัง KControllerAbstract ด้านบนสนับสนุน "รูปแบบการออกแบบกลยุทธ์" โดยให้เครื่องมือสำหรับนักพัฒนาในการสรุปสิ่งที่แตกต่างออกไปก่อนที่จะเขียนโค้ดหนึ่งบรรทัด ความจริงที่ว่าวิธี mixin() เป็นส่วนหนึ่งของส่วนขยายของ KObject ทุกครั้งหมายความว่าคุณสามารถกำหนดและเพิ่มอินเทอร์เฟซการจัดการพฤติกรรมอื่น ๆ ให้กับวัตถุส่วนใหญ่ได้ทันที

บริการและตัวระบุทรัพยากรและตัวระบุตำแหน่ง: แยกชื่อคลาสของฉันออกจากวัตถุของฉัน

บริการและตัวระบุทรัพยากรและตัวระบุตำแหน่งใน Nooku ยังให้การสนับสนุนที่มีประสิทธิภาพสำหรับการแยกข้อกังวล

อีกครั้งให้ดูที่ KObject อีกครั้ง แต่ยังรวมถึง KService เราสามารถปฏิบัติต่อสิ่งต่างๆ ส่วนใหญ่ใน Nooku เป็นบริการหรือทรัพยากร และยกตัวอย่างและซักถามพวกเขาในลักษณะเดียวกันทุกประการ

เมื่อคุณไปที่ร้านขายของชำและซื้อผลิตภัณฑ์ ให้คิดว่าร้านเป็นบริการ กล่าวคือ คอลเลกชั่นของรายการที่คุณสามารถ B แถว; และผลิตภัณฑ์เป็นทรัพยากร กล่าวคือ ตรรกะของรายการ/โซลูชันเดียวที่สามารถ:

• ดูเฉพาะ ( R ead ) (เช่น ดูซุปมะเขือเทศกระป๋อง)
• ย้ายไปรอบ ๆ ร้าน ( E dited) (เช่น ย้ายซุปไปที่ทางเดินผลิตผล)
• เพิ่มหรือลบออกจากสินค้าคงคลังของร้านค้า ( A dd และ D elete) (เช่น เพิ่มซุปชนิดใหม่และกำจัดมะเขือเทศ)

นำตัวอย่างนี้ให้ดียิ่งขึ้น สมมติว่าร้านขายของชำมีแผนกแฟรนไชส์และคุณต้องการทำธุรกิจ ในสถานการณ์นั้น บริการคือแผนกแฟรนไชส์และทรัพยากรคือร้านขายของชำที่คุณซื้อ เป็นการจำแนกตามบริบทเป็นอย่างมาก โดยรวมแล้ว สิ่งนี้เรียกว่ารูปแบบการดำเนินการ BREAD (คุณจะเห็นแต่ละรูปแบบแสดงระหว่าง KControllerService และ KControllerResource ที่นำหน้าด้วย '_action' เช่น _actionRead())

โมเดลสามารถเป็นบริการได้ อ็อบเจ็กต์ตารางสามารถถือเป็นบริการได้ MVC สามกลุ่มเฉพาะจะถูกสร้างอินสแตนซ์เป็นทรัพยากรหรือบริการ ในขณะที่เร็กคอร์ดเฉพาะที่เป็นผลมาจากการสอบสวนบริการสามารถถือเป็นทรัพยากรได้

ทุกอ็อบเจ็กต์ใน Nooku เป็นองค์ประกอบของอ็อบเจ็กต์โดยที่ทุกอ็อบเจ็กต์มีการอ้างอิงถึงบริการที่สร้างอินสแตนซ์ของแอปพลิเคชันทั้งหมดใน 'คอนเทนเนอร์บริการ' และวิธีการเข้าถึงบริการที่เรียกว่า getService() ทั้งหมดที่ต้องใช้โดยวิธีการ KObject::getService() คือเราส่งตัวระบุทรัพยากรที่ถูกต้องและจะส่งคืนบริการที่สร้างอินสแตนซ์ที่พร้อมใช้งาน

ในการพัฒนาแอปพลิเคชันอย่างรวดเร็วของ PHP ตัวระบุทรัพยากรทำให้เรามีวิธีที่มีประสิทธิภาพในการแยกการสร้างอินสแตนซ์ของวัตถุออกจากชื่อคลาส และด้วยเหตุนี้จึงมีนามแฝงสำหรับการระบุตัวตนนั้น สิ่งนี้มีนัยสำคัญต่อความสามารถในการบำรุงรักษาแอปพลิเคชัน นามแฝงของนักพัฒนาสามารถเปลี่ยนคลาสที่ใช้โดยทุกอ็อบเจ็กต์ซึ่งสร้างอินสแตนซ์ด้วยตัวระบุที่กำหนดโดยการเพิ่มโค้ดหนึ่งบรรทัดด้วย KService::addAlias()

ตัวอย่างของตัวระบุทรัพยากรที่เราคุ้นเคยคือ URI หรือ Uniform Resource Identifier:

นี่คือข้อมูลทั้งหมดที่จำเป็นสำหรับ KService ในการค้นหาและโหลดคลาสที่เหมาะสม ชิ้นส่วนเหล่านี้เข้ากันกับการตั้งชื่อคลาสและรูปแบบการจัดตำแหน่งของ Nooku ซึ่งทำให้สามารถคาดการณ์ตำแหน่งและการสร้างอินสแตนซ์ได้ ตัวอย่างตัวระบุจากด้านบน (com://site/user.database.table.user) พยายามโหลดไฟล์ /components/com_user/databases/tables/user.php ซึ่งมีชื่อคลาสของ ComUserDatabaseTableUser อนึ่ง ถ้าไม่มีไฟล์ เฟรมเวิร์กจะให้ออบเจ็กต์ตารางเริ่มต้นแก่คุณ และสร้างมันตามการตั้งชื่อฐานข้อมูลและแบบแผน id schema (สิ่งนี้ทำให้ฉันสนใจมากกว่านี้) ตามที่กล่าวไว้ก่อนหน้านี้ KService ยังอนุญาตให้คุณตั้งค่านามแฝงสำหรับตัวระบุของคุณ ใช้ KService::setAlias('maindbaseadapter','com://admin/default.database.adapter.mysqli') ; ให้เราโหลดวัตถุ db ด้วย KService::getService('maindbaseadapter')

สิ่งนี้ทำให้เราแยกส่วนที่เราพูดถึงและให้ข้อได้เปรียบที่ชัดเจนในการบำรุงรักษาและการขยายแอปพลิเคชันของเรา เรามีอิสระที่จะสร้างแอปพลิเคชันอื่นนอกเหนือจาก 'ไซต์' และ 'ผู้ดูแลระบบ' หากจำเป็น และผ่านทางตัวระบุที่อธิบายในที่นี้ สามารถใช้บริการที่อยู่ในแอปพลิเคชันอื่นๆ ได้อย่างง่ายดาย เพื่อช่วยให้โซลูชันของเราตอบสนองความต้องการของพวกเขา อีกครั้ง นี่เป็นอีกตัวอย่างหนึ่งของวิธีที่ Nooku ให้การสนับสนุน PHP และ RAD แก่นักพัฒนา PHP และ RAD สำหรับองค์ประกอบของออบเจ็กต์คลาสเดียว แต่ยังรวมถึงบริการและแอปพลิเคชันทั้งหมด… ฟรี

สรุป

ด้วยองค์ประกอบเหนือมรดกที่หัวใจ; องค์ประกอบและโครงสร้างที่ชาญฉลาดและมีอยู่ก่อนแล้วเพื่อรองรับการผสมผสานเพิ่มเติม และสถาปัตยกรรมที่เน้นบริการฟรีพร้อมตัวระบุที่อธิบายไว้ที่นี่ Nooku ให้เฟรมเวิร์ก RAD ที่ทรงพลังพร้อมการเริ่มต้นที่สำคัญเหนือเครื่องมือการพัฒนา PHP แบบเพียร์ใดๆ