ผู้ควบคุม

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

ใน ASP.NET MVC Framework ตัวควบคุมคือคลาส .NET ที่มีตรรกะที่จำเป็นในการประมวลผลคำขอ บทบาทของคอนโทรลเลอร์คือการห่อหุ้มตรรกะของแอปพลิเคชัน กล่าวอีกนัยหนึ่ง ผู้ควบคุมมีหน้าที่รับผิดชอบในการประมวลผลคำขอที่เข้ามาและดำเนินการกับโมเดล สาขาวิชาและเลือกมุมมองเพื่อให้ผู้ใช้เห็นภาพ

แอปพลิเคชันตัวอย่าง

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

ในหน้าต่างคอนโซล Visual Studio NuGet Package Manager ให้ป้อนคำสั่งต่อไปนี้:

ติดตั้งแพ็คเกจ Microsoft.Aspnet.Mvc - เวอร์ชัน 5.0.0 - ชื่อโครงการ ControllersAndActions.Tests

หลังจากสร้างโครงการแล้ว ให้เลือกคุณสมบัติ ControllersAndActions จากเมนูโครงการใน Visual Studio ในกล่องโต้ตอบที่เปิดขึ้น ให้ไปที่แท็บเว็บแล้วตรวจสอบปุ่มตัวเลือกหน้าเฉพาะ ( เฉพาะหน้า) ในหมวดเริ่มการดำเนินการ ไม่จำเป็นต้องป้อนค่าใดๆ เพียงเลือกปุ่มตัวเลือก

แนวคิดของตัวควบคุม

คุณเคยเห็นกรณีการใช้งานสำหรับคอนโทรลเลอร์ในบทความ ASP.NET MVC ก่อนหน้านี้เกือบทั้งหมด ถึงเวลาชมเบื้องหลังแล้ว

การสร้างคอนโทรลเลอร์โดยใช้อินเทอร์เฟซ IController

ใน MVC Framework คลาสคอนโทรลเลอร์ต้องใช้อินเทอร์เฟซ IController จากเนมสเปซ System.Web.Mvcแสดงในตัวอย่างด้านล่าง:

การใช้ System.Web.Routing; เนมสเปซ System.Web.Mvc (อินเทอร์เฟซสาธารณะ IController ( ดำเนินการเป็นโมฆะ (RequestContext requestContext); ) )

ในการรับคำจำกัดความของอินเทอร์เฟซนี้ คุณต้องดาวน์โหลดซอร์สโค้ด MVC Framework ซึ่งมีประโยชน์อย่างมากในการค้นหาการทำงานภายในของเครื่องมือเฟรมเวิร์ก

อย่างที่คุณเห็นอินเทอร์เฟซ IController นั้นเรียบง่ายมาก ของเขาเท่านั้น ดำเนินการ() วิธีการเรียกว่าเมื่อมีการส่งคำขอไปยังคลาสคอนโทรลเลอร์นี้ กรอบงาน MVC จะระบุว่าคำขอกำหนดเป้าหมายคลาสใดโดยการอ่านค่าของคุณสมบัติตัวควบคุมที่สร้างโดยข้อมูลการกำหนดเส้นทางหรือผ่านคลาสการกำหนดเส้นทางพิเศษ

คุณสามารถสร้างคลาสคอนโทรลเลอร์ได้โดยใช้อินเทอร์เฟซ IController แต่เนื่องจากอินเทอร์เฟซนี้เป็นระดับต่ำ คุณจึงต้องทำงานหนักมากเพื่อให้ได้สิ่งที่มีประโยชน์ อย่างไรก็ตาม อินเทอร์เฟซ IController มีประโยชน์สำหรับการสาธิตการทำงานของคอนโทรลเลอร์ และเพื่อจุดประสงค์นี้ ไฟล์คลาสใหม่ที่เรียกว่า BasicController.cs จะถูกสร้างขึ้นในโฟลเดอร์ Controllers เนื้อหาดังกล่าวจะแสดงอยู่ในตัวอย่างด้านล่าง:

ใช้ System.Web.Mvc; โดยใช้ System.Web.Routing; Namespace ControllersAndActions.Controllers (คลาสสาธารณะ BasicController: IController ( public void Execute(RequestContext requestContext) ( string controller = (string)requestContext.RouteData.Values["controller"]; string action = (string)requestContext.RouteData.Values["action "]; requestContext.HttpContext.Response.Write(string.Format("Controller: (0), Action Method: (1)", controller, action)); ) ) )

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

วัตถุ HttpContextBase ให้การเข้าถึงชุดของวัตถุที่อธิบายคำขอปัจจุบัน เรียกว่าวัตถุบริบท เราจะกลับมาหาพวกเขาในภายหลัง วัตถุ RouteData อธิบายเส้นทาง คุณสมบัติที่สำคัญของคลาส RouteData แสดงอยู่ในตารางด้านล่าง:

บทความการกำหนดค่าระบบการกำหนดเส้นทางแสดงวิธีใช้ประเภท RouteBase และ IRouteHandler เพื่อกำหนดค่าระบบการกำหนดเส้นทาง ในตัวอย่างที่อยู่ระหว่างการพิจารณา เมื่อใช้คุณสมบัติ Values ​​ค่าของตัวควบคุมและตัวแปรเซ็กเมนต์การดำเนินการจะได้รับซึ่งจะถูกเขียนลงในการตอบสนอง

ส่วนหนึ่งของปัญหาในการสร้างตัวควบคุมแบบกำหนดเองคือการไม่สามารถเข้าถึงคุณลักษณะต่างๆ เช่น มุมมองได้ ซึ่งหมายความว่าคุณต้องทำงานในระดับที่ต่ำกว่าซึ่งอธิบายการเขียนเนื้อหาโดยตรงเพื่อตอบสนองต่อลูกค้า คุณสมบัติ HttpContextBase.การตอบสนองส่งคืนวัตถุ HttpResponseBase ที่อนุญาตให้คุณกำหนดค่าและเพิ่มเนื้อหาในการตอบกลับที่จะส่งไปยังไคลเอนต์ นี่เป็นอีกจุดติดต่อระหว่างแพลตฟอร์ม ASP.NET และ MVC Framework

หากคุณเรียกใช้แอปพลิเคชันและไปที่ URL เช่น /Basic/Index ตัวควบคุมพิเศษจะสร้างเอาต์พุตดังแสดงในรูปด้านล่าง:

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

คลาสที่มีชื่อลงท้ายด้วย Base

MVC Framework อาศัยเฟรมเวิร์ก ASP.NET ในการประมวลผลคำขอ ซึ่งสมเหตุสมผลมากเพราะ... แพลตฟอร์มนี้เป็นการใช้งานที่ได้รับการพิสูจน์แล้วและมีฟีเจอร์หลากหลายซึ่งผสานรวมกับเซิร์ฟเวอร์แอปพลิเคชัน IIS อย่างแน่นหนา ปัญหาคือคลาสที่ ASP.NET ใช้เพื่อจัดเตรียมข้อมูลคำขอไม่เหมาะสำหรับการทดสอบหน่วย ซึ่งเป็นประโยชน์หลักของการใช้ MVC Framework

Microsoft ตัดสินใจที่จะแนะนำความสามารถในการทดสอบโดยยังคงรักษาความเข้ากันได้ด้วย แอปพลิเคชันที่มีอยู่ ASP.NET Web Forms ดังนั้นผลลัพธ์ที่ได้คือ ชั้นเรียนพื้นฐาน- คลาสเหล่านี้ถูกเรียกเช่นนี้เพราะมีชื่อเดียวกันกับคลาสหลักของเฟรมเวิร์ก ASP.NET ตามด้วยคำว่า Base

ตัวอย่างเช่น กรอบงาน ASP.NET ให้ข้อมูลเชิงบริบทเกี่ยวกับคำขอปัจจุบันและบริการแอปพลิเคชันหลักจำนวนหนึ่งผ่านวัตถุ HttpContext คลาสฐานที่สอดคล้องกันคือ HttpContextBase ซึ่งเป็นอินสแตนซ์ที่ถูกส่งผ่านไปยังเมธอด Execute() ที่กำหนดไว้ในอินเทอร์เฟซ IController (คลาสฐานอื่น ๆ จะถูกสาธิตในตัวอย่างต่อ ๆ ไป) คลาสดั้งเดิมและคลาส Base กำหนดคุณสมบัติและเมธอดเดียวกัน แต่เป็นคลาส Base เป็นนามธรรมเสมอซึ่งหมายความว่าใช้งานง่ายสำหรับการทดสอบหน่วย

บางครั้งคุณจะพบอินสแตนซ์ของคลาส ASP.NET ดั้งเดิมตัวใดตัวหนึ่ง เช่น HttpContext ในกรณีนี้ คุณต้องสร้างคลาส Base ที่เป็นมิตรกับ MVC ซึ่งคล้ายกับ HttpContextBase นี้จะกระทำโดยใช้อย่างใดอย่างหนึ่ง คลาส Wrapperซึ่งมีชื่อเหมือนกับคลาสดั้งเดิมต่อท้ายด้วยคำว่า Wrapper เช่น HttpContextWrapper คลาส Wrapper มาจากคลาส Base และมีคอนสตรัคเตอร์ที่ยอมรับอินสแตนซ์ของคลาสดั้งเดิม:

คลาสดั้งเดิม คลาสพื้นฐาน และคลาส Wrapper ถูกกำหนดไว้ในเนมสเปซ System.Web ดังนั้นเฟรมเวิร์ก ASP.NET จึงสามารถรองรับ MVC Framework และแอปพลิเคชันรุ่นเก่าได้อย่างราบรื่น แอปพลิเคชันบนเว็บแบบฟอร์ม

การสร้างคอนโทรลเลอร์โดยสืบทอดจากคลาสคอนโทรลเลอร์

ดังที่แสดงในตัวอย่างก่อนหน้านี้ MVC Framework ช่วยให้สามารถปรับแต่งและขยายได้ไม่จำกัด หากต้องการจัดเตรียมการประมวลผลแบบสอบถามและการสร้างผลลัพธ์ตามต้องการ คุณสามารถใช้อินเทอร์เฟซ IController ได้ ไม่ชอบวิธีดำเนินการใช่ไหม? ไม่ต้องการกังวลเกี่ยวกับการแสดงผลมุมมอง? ในกรณีนี้ คุณสามารถจัดการเรื่องต่างๆ ด้วยตนเองและปรับใช้วิธีที่ดีกว่า เร็วขึ้น และสวยงามยิ่งขึ้นในการจัดการคำขอ หรือคุณสามารถใช้ประโยชน์จากเครื่องมือที่นำเสนอโดยทีม MVC Framework ที่ Microsoft และสืบทอดตัวควบคุมของคุณจากคลาส System.Web.Mvc.Controller

คลาสคอนโทรลเลอร์ให้การสนับสนุนการประมวลผลคำขอที่นักพัฒนาแอปพลิเคชัน MVC ส่วนใหญ่คุ้นเคย ใช้ในตัวอย่างทั้งหมดที่กล่าวถึงในบทความก่อนหน้านี้ คลาส Controller มีสามคลาส หมายถึงคีย์ซึ่งอธิบายไว้ด้านล่าง:

วิธีดำเนินการ

พฤติกรรมของคอนโทรลเลอร์แพร่กระจายไปในหลายวิธี (แทนที่จะนำไปใช้ในรูปแบบ วิธีการเดียวเท่านั้นดำเนินการ()) วิธีการดำเนินการแต่ละวิธีจะถูกแมปกับ URL ที่เกี่ยวข้องและเรียกพร้อมกับพารามิเตอร์ที่ดึงมาจากคำขอที่เข้ามา

ผลลัพธ์ของการกระทำ

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

ตัวกรอง

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

แนวทางที่ดีที่สุดในการสร้างคอนโทรลเลอร์คือการรับมาจากคลาสคอนโทรลเลอร์ซึ่งเป็นสิ่งที่ Visual Studio ทำอย่างที่คุณคาดหวังเมื่อสร้างเว้นแต่ว่าคุณกำลังจัดการกับข้อกำหนดเฉพาะ ชั้นเรียนใหม่ตอบสนองต่อรายการเมนู Add --> Scaffold (เพิ่ม --> Template)

ตัวอย่างด้านล่างแสดงรหัส ตัวควบคุมที่เรียบง่ายเรียกว่า DerivedController ซึ่งสร้างขึ้นในลักษณะเดียวกัน มันถูกสร้างขึ้นโดยใช้ตัวควบคุม MVC 5 - ตัวเลือกว่างที่มีหลายตัว การเปลี่ยนแปลงง่ายๆมีไว้สำหรับการตั้งค่าคุณสมบัติ ViewBag และการเลือกมุมมอง:

การใช้ระบบ; ใช้ System.Web; ใช้ System.Web.Mvc; Namespace ControllersAndActions.Controllers ( คลาสสาธารณะ DerivedController: คอนโทรลเลอร์ ( สาธารณะ ActionResult Index() ( ViewBag.Message = "สวัสดีจากคอนโทรลเลอร์ DerivedController วิธีการกระทำ Index"; return View("MyView"); ) ) )

คลาส Controller ยังจัดให้มีการสื่อสารกับระบบมุมมอง Razor ในตัวอย่างนี้ เราส่งคืนผลลัพธ์ของการเรียกไปยังเมธอด View() ซึ่งถูกส่งเป็นพารามิเตอร์ชื่อมุมมองเพื่อแสดงให้กับลูกค้า หากต้องการสร้างมุมมองนี้ ให้สร้างโฟลเดอร์ Views/Derived คลิกที่โฟลเดอร์นั้น คลิกขวาเมาส์แล้วเลือกเข้า เมนูบริบทรายการ เพิ่ม --> หน้าดู MVC 5 (มีดโกน) (เพิ่ม --> หน้าดู MVC 5 (มีดโกน)) ระบุชื่อ MyView.cshtml และคลิก ตกลง เพื่อสร้างไฟล์มุมมอง

นำเนื้อหาของไฟล์ตามตัวอย่าง:

@( ViewBag.Title = "Index"; } MyView Сообщение от контроллера: « @ViewBag.Message »!}

หลังจากเรียกใช้แอปพลิเคชันและนำทางไปยัง URL มุมมอง /Derived/Index แล้ว วิธีการดำเนินการนี้จะถูกเรียกและ MyView จะถูกเรนเดอร์:

การสืบทอดจากคลาส Controller ส่งผลให้จำเป็นต้องใช้วิธีดำเนินการ รับอินพุตใดๆ ที่จำเป็นในการประมวลผลคำขอ และสร้างการตอบสนองที่เหมาะสม บทความต่อไปนี้อธิบายวิธีการต่างๆ ในการทำเช่นนี้

หลายคนเริ่มเขียนโปรเจ็กต์เพื่อทำงานกับงานเดียว โดยไม่ได้หมายความว่าสามารถเติบโตไปสู่ระบบการจัดการที่มีผู้ใช้หลายราย เช่น เนื้อหาหรือ God Forbid การผลิต และทุกอย่างดูดีและเจ๋ง ทุกอย่างทำงานได้ดี จนกว่าคุณจะเริ่มเข้าใจว่าโค้ดที่เขียนนั้นประกอบด้วยไม้ค้ำยันและฮาร์ดโค้ดทั้งหมด โค้ดผสมกับเลย์เอาต์ ข้อความค้นหา และไม้ค้ำยัน ซึ่งบางครั้งก็อ่านไม่ออกด้วยซ้ำ ปัญหาเร่งด่วนเกิดขึ้น: เมื่อเพิ่มคุณสมบัติใหม่คุณต้องแก้ไขโค้ดนี้เป็นเวลานานโดยจำได้ว่า "เขียนอะไรอยู่ที่นั่น" และสาปแช่งตัวเองในอดีต

คุณอาจเคยได้ยินเกี่ยวกับรูปแบบการออกแบบและได้อ่านหนังสือที่ยอดเยี่ยมเหล่านี้ด้วยซ้ำ:

• E. Gamma, R. Helm, R. Johnson, J. Vlissides “เทคนิคเชิงวัตถุประสงค์ การออกแบบที่มุ่งเน้น- รูปแบบการออกแบบ";
• M. Fowler "สถาปัตยกรรมแอปพลิเคชันซอฟต์แวร์ระดับองค์กร"

และหลายคนไม่สะทกสะท้านกับคู่มือและเอกสารขนาดใหญ่ พยายามศึกษากรอบงานสมัยใหม่ใดๆ และต้องเผชิญกับความซับซ้อนของความเข้าใจ (เนื่องจากการมีอยู่ของแนวคิดทางสถาปัตยกรรมมากมายที่เชื่อมโยงกันอย่างชาญฉลาด) ทำให้การศึกษาและการใช้ เครื่องมือทันสมัย ​​“อยู่หลังเตา”

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

โปรแกรมเมอร์ PHP ผู้ช่ำชองไม่น่าจะพบสิ่งใหม่สำหรับตัวเองในบทความนี้ แต่ความคิดเห็นและความคิดเห็นเกี่ยวกับข้อความหลักจะมีประโยชน์มาก! เพราะ หากไม่มีทฤษฎี การฝึกฝนก็เป็นไปไม่ได้ และหากไม่มีการฝึกฝน ทฤษฎีก็จะไร้ประโยชน์ จากนั้นจะมีทฤษฎีเล็กๆ น้อยๆ ก่อน แล้วจึงค่อยไปสู่การปฏิบัติ หากคุณคุ้นเคยกับแนวคิด MVC อยู่แล้ว คุณสามารถข้ามส่วนทฤษฎีและไปที่แบบฝึกหัดได้เลย

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

ลองดูแผนภาพแนวคิดของรูปแบบ MVC (ในความคิดของฉัน นี่เป็นแผนภาพที่ประสบความสำเร็จมากที่สุดที่ฉันเคยเห็น):

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

โฟลว์ทั่วไปของแอปพลิเคชัน MVC สามารถอธิบายได้ดังต่อไปนี้:

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

แอปพลิเคชันได้รับการร้องขอจากผู้ใช้และกำหนดตัวควบคุมและการดำเนินการที่ร้องขอ ในกรณีของหน้าหลัก จะมีการดำเนินการเริ่มต้น ( ดัชนี).

แอปพลิเคชันจะสร้างอินสแตนซ์ของคอนโทรลเลอร์และรันวิธีดำเนินการ
ซึ่งตัวอย่างเช่นมีการเรียกโมเดลที่อ่านข้อมูลจากฐานข้อมูล

หลังจากนั้น การดำเนินการจะสร้างมุมมองพร้อมข้อมูลที่ได้รับจากแบบจำลองและแสดงผลลัพธ์ให้ผู้ใช้เห็น

โมเดล - ประกอบด้วยตรรกะทางธุรกิจของแอปพลิเคชันและรวมถึงวิธีการสุ่มตัวอย่าง (ซึ่งอาจเป็นวิธี ORM) การประมวลผล (เช่น กฎการตรวจสอบ) และการให้ข้อมูลเฉพาะ ซึ่งมักจะทำให้หนามาก ซึ่งเป็นเรื่องปกติ
โมเดลไม่ควรโต้ตอบกับผู้ใช้โดยตรง ตัวแปรทั้งหมดที่เกี่ยวข้องกับคำขอของผู้ใช้จะต้องได้รับการประมวลผลในคอนโทรลเลอร์
โมเดลไม่ควรสร้าง HTML หรือโค้ดแสดงผลอื่นที่สามารถเปลี่ยนแปลงได้ขึ้นอยู่กับความต้องการของผู้ใช้ รหัสดังกล่าวควรได้รับการประมวลผลในมุมมอง
ตัวอย่างเช่น โมเดลเดียวกัน: โมเดลการตรวจสอบสิทธิ์ผู้ใช้สามารถใช้ได้ทั้งในส่วนผู้ใช้และผู้ดูแลระบบของแอปพลิเคชัน ในกรณีนี้ก็รับได้ รหัสทั่วไปลงในคลาสที่แยกจากกันและสืบทอดจากคลาสนั้น โดยกำหนดวิธีการเฉพาะสำหรับแอปพลิเคชันย่อยในคลาสที่สืบทอด

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

คอนโทรลเลอร์คือกาวที่เชื่อมต่อโมเดล มุมมอง และส่วนประกอบอื่นๆ เข้าด้วยกัน แอปพลิเคชันทำงาน- ผู้ควบคุมมีหน้าที่รับผิดชอบในการประมวลผลคำขอของผู้ใช้ คอนโทรลเลอร์ไม่ควรมีการสืบค้น SQL เก็บไว้เป็นโมเดลจะดีกว่า ตัวควบคุมไม่ควรมี HTML หรือมาร์กอัปอื่นๆ มันคุ้มค่าที่จะนำมาแสดง
ในแอปพลิเคชัน MVC ที่ออกแบบมาอย่างดี คอนโทรลเลอร์มักจะบางมากและมีโค้ดเพียงไม่กี่สิบบรรทัด สิ่งเดียวกันนี้ไม่สามารถพูดได้เกี่ยวกับ Stupid Fat Controllers (SFC) ใน CMS Joomla ตรรกะของตัวควบคุมค่อนข้างเป็นแบบอย่างและส่วนใหญ่จะดำเนินการใน คลาสพื้นฐาน.
ในทางกลับกันโมเดลนั้นมีความหนามากและมีโค้ดส่วนใหญ่ที่เกี่ยวข้องกับการประมวลผลข้อมูลเพราะว่า โครงสร้างข้อมูลและตรรกะทางธุรกิจที่อยู่ภายในนั้นมักจะค่อนข้างเฉพาะเจาะจงกับแอปพลิเคชันเฉพาะ

1.1. Front Controller และ Page Controller ในกรณีส่วนใหญ่ การโต้ตอบของผู้ใช้กับเว็บแอปพลิเคชันเกิดขึ้นผ่านการคลิกลิงก์ ดูที่แถบที่อยู่ของเบราว์เซอร์ของคุณ - คุณได้รับข้อความนี้จากลิงก์นี้ ลิงก์อื่นๆ เช่น ทางด้านขวาของหน้านี้ จะให้เนื้อหาที่แตกต่างแก่คุณ ดังนั้นลิงก์จึงแสดงถึงคำสั่งเฉพาะไปยังเว็บแอปพลิเคชัน

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

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

รหัสการประมวลผลโดยประมาณในกรณีนี้:
switch($_GET["action"]) ( case "about" : need_once("about.php"); // "เกี่ยวกับเรา" ตัวแบ่งหน้า; case "contacts" : need_once("contacts.php"); // ตัวแบ่งหน้า "ผู้ติดต่อ" : need_once("feedback.php"); // หน้า "Feedback" ค่าเริ่มต้น: need_once("page404.php"); // หน้า "404"
ฉันคิดว่าเกือบทุกคนเคยทำสิ่งนี้มาก่อน

ด้วยการใช้กลไกการกำหนดเส้นทาง URL คุณสามารถกำหนดค่าแอปพลิเคชันของคุณให้ยอมรับคำขอเช่นนี้เพื่อแสดงข้อมูลเดียวกัน:
http://www.example.com/contacts/feedback

ที่นี่ผู้ติดต่อแสดงถึงตัวควบคุมและข้อเสนอแนะคือวิธีการควบคุมผู้ติดต่อที่แสดงแบบฟอร์ม ข้อเสนอแนะฯลฯ เราจะกลับมาที่ปัญหานี้ในภาคปฏิบัติ

นอกจากนี้ยังควรทราบด้วยว่าเราเตอร์ของเฟรมเวิร์กเว็บจำนวนมากอนุญาตให้คุณสร้างได้ตามใจชอบ เส้นทาง URL(ระบุความหมายของแต่ละส่วนของ URL) และกฎสำหรับการประมวลผล
ตอนนี้เรามีความรู้ทางทฤษฎีเพียงพอที่จะนำไปปฏิบัติแล้ว

2. ฝึกฝนก่อน มาสร้างกัน โครงสร้างต่อไปนี้ไฟล์และโฟลเดอร์:

เมื่อมองไปข้างหน้า ฉันจะบอกว่าคลาสหลัก Model, View และ Controller จะถูกจัดเก็บไว้ในโฟลเดอร์หลัก
ลูกๆ ของพวกเขาจะถูกจัดเก็บไว้ในไดเร็กทอรีคอนโทรลเลอร์ โมเดล และมุมมอง ไฟล์ index.php เป็นจุดเริ่มต้นเข้าสู่แอปพลิเคชัน ไฟล์ bootstrap.php เริ่มต้นการโหลดแอปพลิเคชัน เชื่อมต่อโมดูลที่จำเป็นทั้งหมด ฯลฯ

เราจะไปตามลำดับ มาเปิดไฟล์ index.php แล้วกรอกโค้ดต่อไปนี้:
ini_set("display_errors", 1); need_once "application/bootstrap.php";
ไม่ควรมีคำถามใดๆ ที่นี่

ต่อไปไปที่ไฟล์ bootstrap.php ทันที:
need_once "core/model.php"; need_once "core/view.php"; need_once "core/controller.php"; need_once "core/route.php"; เส้นทาง::เริ่มต้น(); //เริ่มเราเตอร์
สามบรรทัดแรกจะรวมไฟล์เคอร์เนลที่ไม่มีอยู่ในปัจจุบัน บรรทัดสุดท้ายเชื่อมต่อไฟล์กับคลาสเราเตอร์และเปิดใช้งานเพื่อดำเนินการโดยการโทร วิธีการคงที่เริ่ม.

2.1. การใช้เราเตอร์ URL สำหรับตอนนี้ เรามาเบี่ยงเบนไปจากการใช้รูปแบบ MVC และมุ่งเน้นไปที่การกำหนดเส้นทาง ขั้นตอนแรกที่เราต้องทำคือเขียนโค้ดต่อไปนี้ใน .htaccess:
RewriteEngine บน RewriteCond %(REQUEST_FILENAME) !-f RewriteCond %(REQUEST_FILENAME) !-d RewriteRule .* index.php [L]
โค้ดนี้จะเปลี่ยนเส้นทางการประมวลผลเพจทั้งหมดไปที่ index.php ซึ่งเป็นสิ่งที่เราต้องการ จำในส่วนแรกที่เราพูดถึง Front Controller ได้ไหม!

เราจะวางการกำหนดเส้นทางไว้ในไฟล์ Route.php แยกต่างหากในไดเร็กทอรีหลัก ในไฟล์นี้ เราจะอธิบายคลาส Route ซึ่งจะเรียกใช้เมธอดคอนโทรลเลอร์ ซึ่งจะสร้างมุมมองเพจขึ้นมา

เนื้อหาของไฟล์ Route.php

เส้นทางคลาส ( ฟังก์ชั่นคงที่ start() ( // ตัวควบคุมและการกระทำเริ่มต้น $controller_name = "Main"; $action_name = "index"; $routes = explode("/", $_SERVER["REQUEST_URI"]); // get ชื่อคอนโทรลเลอร์ if (!empty($routes)) ( $controller_name = $routes; ) // รับชื่อการดำเนินการ if (!empty($routes)) ( $action_name = $routes; ) // เพิ่มคำนำหน้า $model_name = " Model_".$controller_name; $controller_name = "Controller_".$controller_name; $action_name = "action_".$action_name; // เชื่อมต่อไฟล์กับคลาสโมเดล (อาจไม่มีไฟล์โมเดล) $model_file = strtolower ($model_name). ".php"; $model_path = "application/models/".$model_file; if(file_exists($model_path)) ( รวม "application/models/".$model_file; ) // เชื่อมต่อไฟล์ ด้วยคลาสคอนโทรลเลอร์ $controller_file = strtolower ($controller_name).php"; $controller_path = "application/controllers/".$controller_file; if(file_exists($controller_path)) ( include "application/controllers/".$controller_file; ) else ( /* มันจะถูกต้องถ้าส่งข้อยกเว้นที่นี่ แต่เพื่อให้ง่ายขึ้น เราจะเปลี่ยนเส้นทางไปยังหน้า 404 ทันที */ Route::ErrorPage404(); ) // สร้างคอนโทรลเลอร์ $controller = new $controller_name ; $action = $action_name; if(method_exists($controller, $action)) ( // เรียกคอนโทรลเลอร์ action $controller->$action(); ) else ( // ที่นี่จะฉลาดกว่าถ้าโยนข้อยกเว้น Route::ErrorPage404(); ) ) ฟังก์ชั่น ErrorPage404( ) ( $host = "http://".$_SERVER["HTTP_HOST"]."/"; header("HTTP/1.1 404 Not Found"); header("Status: 404 Not Found") ; header(" ตำแหน่ง:".$host"404");

ฉันสังเกตว่าคลาสใช้ตรรกะที่เรียบง่ายมาก (แม้จะมีโค้ดมากมาย) และอาจมีปัญหาด้านความปลอดภัยด้วยซ้ำ ที่ทำโดยตั้งใจเพราะว่า... การเขียนคลาสการกำหนดเส้นทางที่ครบถ้วนควรได้รับบทความแยกต่างหากเป็นอย่างน้อย มาดูประเด็นหลักๆ กัน...

องค์ประกอบอาร์เรย์ส่วนกลาง $_SERVER["REQUEST_URI"] ประกอบด้วย ที่อยู่แบบเต็มที่ผู้ใช้ติดต่อมา
ตัวอย่างเช่น: example.ru/contacts/feedback

การใช้ฟังก์ชัน ระเบิดที่อยู่แบ่งออกเป็นส่วนประกอบ ผลลัพธ์ที่ได้คือชื่อของคอนโทรลเลอร์ ตามตัวอย่างที่กำหนด นี่คือคอนโทรลเลอร์ ผู้ติดต่อและชื่อของการกระทำ ในกรณีของเรา - ข้อเสนอแนะ.

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

ดังนั้นเมื่อไป เช่น ที่อยู่:
example.com/portfolio
หรือ
example.com/portfolio/index
เราเตอร์จะดำเนินการดังต่อไปนี้:

จะรวมไฟล์ model_portfolio.php จากโฟลเดอร์ models ซึ่งมีคลาส Model_Portfolio

จะรวมไฟล์ controller_portfolio.php จากโฟลเดอร์ controllers ซึ่งมีคลาส Controller_Portfolio

จะสร้างอินสแตนซ์ของคลาส Controller_Portfolio และเรียกใช้การดำเนินการเริ่มต้น - action_index ตามที่อธิบายไว้ในนั้น

หากผู้ใช้พยายามเข้าถึงที่อยู่ของคอนโทรลเลอร์ที่ไม่มีอยู่จริง ตัวอย่างเช่น:
example.com/ufo
จากนั้นเขาจะถูกนำไปที่หน้า "404":
example.com/404
สิ่งเดียวกันนี้จะเกิดขึ้นหากผู้ใช้เข้าถึงการกระทำที่ไม่ได้อธิบายไว้ในคอนโทรลเลอร์2.2. กลับไปที่การใช้งาน MVC ไปที่โฟลเดอร์หลักและเพิ่มไฟล์อีกสามไฟล์ลงในไฟล์ Route.php: model.php, view.php และ controller.php

ฉันขอเตือนคุณว่ามันจะมีคลาสพื้นฐานซึ่งเราจะเริ่มเขียนตอนนี้

เนื้อหาของไฟล์ model.php
โมเดลคลาส ( ฟังก์ชั่นสาธารณะ get_data() ( ) )
คลาสโมเดลมีวิธีดึงข้อมูลว่างเพียงวิธีเดียว ซึ่งจะถูกแทนที่ในคลาสสืบทอด เมื่อเราสร้างคลาสสืบทอด ทุกอย่างจะชัดเจนขึ้น

เนื้อหาของไฟล์ view.php
class View ( //public $template_view; // ที่นี่คุณสามารถระบุมุมมองทั่วไปเริ่มต้นได้ function create($content_view, $template_view, $data = null) ( /* if(is_array($data)) ( // แปลงอาร์เรย์ องค์ประกอบลงในตัวแปร extract($data); ) */ รวม "application/views/".$template_view;
เดาได้ไม่ยากเลยว่าวิธีการ สร้างมีวัตถุประสงค์เพื่อสร้างมุมมอง พารามิเตอร์ต่อไปนี้ถูกส่งไป:

$content_file - มุมมองที่แสดงเนื้อหาของหน้า;

$template_file - เทมเพลตทั่วไปสำหรับทุกหน้า;

$data เป็นอาร์เรย์ที่มีองค์ประกอบเนื้อหาของหน้า มักจะกรอกในแบบจำลอง

ฟังก์ชันรวมจะเชื่อมต่อเทมเพลตทั่วไป (มุมมอง) แบบไดนามิกซึ่งจะฝังมุมมองไว้
เพื่อแสดงเนื้อหาของหน้าเฉพาะ

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

เนื้อหาของไฟล์ controller.php
ตัวควบคุมคลาส ( public $model; public $view; function __construct() ( $this->view = new View(); ) function action_index() ( ) )
วิธี การดำเนินการ_ดัชนี- นี่คือการกระทำที่เรียกโดยค่าเริ่มต้น เราจะแทนที่มันเมื่อใช้คลาสที่สืบทอด

2.3. การใช้งานคลาสลูกหลาน Model และ Controller การสร้าง View ตอนนี้ความสนุกเริ่มต้นขึ้นแล้ว! เว็บไซต์นามบัตรของเราจะประกอบด้วยหน้าต่อไปนี้:

บ้าน

บริการ

ผลงาน

รายชื่อผู้ติดต่อ

และก็ - หน้า "404"

แต่ละหน้าจะมีตัวควบคุมของตนเองจากโฟลเดอร์ตัวควบคุมและมุมมองจากโฟลเดอร์มุมมอง บางเพจอาจใช้โมเดลหรือโมเดลจากโฟลเดอร์โมเดล

ในรูปก่อนหน้านี้ ไฟล์ template_view.php จะถูกเน้นแยกกัน - นี่คือเทมเพลตที่มีมาร์กอัปที่ใช้ได้ทั่วไปในทุกหน้า ในกรณีที่ง่ายที่สุด อาจมีลักษณะดังนี้:
บ้าน
เพื่อให้ไซต์มีรูปลักษณ์ที่เรียบร้อย เราจึงสร้างเทมเพลต CSS และรวมเข้ากับไซต์ของเราโดยการเปลี่ยนโครงสร้างของมาร์กอัป HTML และ การเชื่อมต่อ CSSและไฟล์จาวาสคริปต์:

ในตอนท้ายของบทความ ในส่วน "ผลลัพธ์" จะมีลิงก์ไปยังพื้นที่เก็บข้อมูล GitHub พร้อมโปรเจ็กต์ซึ่งได้ดำเนินการตามขั้นตอนเพื่อรวมเทมเพลตอย่างง่าย

2.3.1. การสร้างหน้าหลัก เริ่มจากคอนโทรลเลอร์ controller_main.php กันก่อน นี่คือโค้ดของมัน:
คลาส Controller_Main ขยายตัวควบคุม ( function action_index() ( $this->view->generate("main_view.php", "template_view.php"); ) )
ในวิธีการ สร้างอินสแตนซ์ของคลาส View ชื่อไฟล์ของเทมเพลตทั่วไปและมุมมองที่มีเนื้อหาของหน้าจะถูกส่งผ่าน
นอกเหนือจากการดำเนินการของดัชนีแล้ว ตัวควบคุมยังสามารถมีการดำเนินการอื่นๆ ได้อีกด้วย

ไฟล์ด้วย ปริทัศน์เราดูก่อนหน้านี้ พิจารณาไฟล์เนื้อหา main_view.php:
ยินดีต้อนรับ!

OLOLOSHA TEAM เป็นทีมผู้เชี่ยวชาญชั้นหนึ่งในด้านการพัฒนาเว็บไซต์ด้วยประสบการณ์หลายปีในการรวบรวมหน้ากากเม็กซิกัน รูปปั้นทองสัมฤทธิ์และหินจากอินเดียและซีลอน ภาพนูนต่ำนูนต่ำและประติมากรรมที่สร้างขึ้นโดยปรมาจารย์แห่งแถบเส้นศูนย์สูตรของแอฟริกาเมื่อห้าหรือหกศตวรรษ ที่ผ่านมา...

ซึ่งประกอบด้วยมาร์กอัปแบบธรรมดาที่ไม่มีการเรียก PHP
หากต้องการแสดงหน้าหลัก คุณสามารถใช้หนึ่งในที่อยู่ต่อไปนี้:

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

2.3.2. การสร้างหน้า “พอร์ตโฟลิโอ” ในกรณีของเรา หน้า “พอร์ตโฟลิโอ” เป็นหน้าเดียวที่ใช้โมเดลนี้
โดยทั่วไปโมเดลจะรวมวิธีการสุ่มตัวอย่างข้อมูล เช่น

วิธีการของไลบรารี pgsql หรือ mysql ดั้งเดิม

วิธีการของไลบรารีที่ใช้ข้อมูลนามธรรม ตัวอย่างเช่นวิธีการของไลบรารี PEAR MDB2;

วิธีการออม;

วิธีการทำงานกับ NoSQL;

และอื่น ๆ.

เพื่อความง่าย เราจะไม่ใช้คำสั่ง SQL หรือคำสั่ง ORM ที่นี่ แต่เราจะจำลองข้อมูลจริงและส่งกลับอาร์เรย์ของผลลัพธ์ทันที
วางไฟล์โมเดล model_portfolio.php ลงในโฟลเดอร์ models นี่คือเนื้อหา:
class Model_Portfolio ขยาย Model ( ฟังก์ชั่นสาธารณะ get_data() ( return array(array("Year" => "2012", "Site" => "http://DunkelBeer.ru", "Description" => "ไซต์ส่งเสริมการขายของ เบียร์ Dunkel สีเข้มจากผู้ผลิตชาวเยอรมัน Löwenbraü ผลิตในรัสเซียโดยบริษัทผลิตเบียร์ "SUN InBev."), array("Year" => "2012", "Site" => "http://ZopoMobile.ru", "คำอธิบาย " => "แคตตาล็อกภาษารัสเซีย โทรศัพท์จีนบริษัท Zopo บน ใช้ระบบปฏิบัติการ Androidระบบปฏิบัติการและอุปกรณ์เสริมสำหรับพวกเขา"), // todo); ) )

คลาส Model Controller มีอยู่ในไฟล์ controller_portfolio.php นี่คือโค้ด:
คลาส Controller_Portfolio ขยายคอนโทรลเลอร์ ( function __construct() ( $this->model = new Model_Portfolio(); $this->view = new View(); ) function action_index() ( $data = $this->model->get_data( ); $this->view->generate("portfolio_view.php", "template_view.php", $data ) )
ให้เป็นตัวแปร ข้อมูลอาร์เรย์ที่ส่งคืนโดยเมธอดจะถูกเขียน get_dataซึ่งเราดูไปแล้ว
ตัวแปรนี้จะถูกส่งผ่านเป็นพารามิเตอร์วิธีการ สร้างซึ่งยังประกอบด้วย: ชื่อของไฟล์ที่มีเทมเพลตทั่วไปและชื่อของไฟล์ที่มีมุมมองพร้อมเนื้อหาของหน้า

มุมมองที่มีเนื้อหาของหน้าอยู่ในไฟล์portfolio_view.php
ผลงาน

โครงการทั้งหมดในตารางต่อไปนี้เป็นเพียงเรื่องสมมติ ดังนั้นอย่าพยายามติดตามลิงก์ที่ให้ไว้ด้วยซ้ำ

ปี

โครงการ

คำอธิบาย

ทุกอย่างเป็นเรื่องง่ายที่นี่ มุมมองจะแสดงข้อมูลที่ได้รับจากแบบจำลอง

2.3.3. การสร้างเพจที่เหลือ เพจที่เหลือถูกสร้างขึ้นในลักษณะเดียวกัน รหัสของพวกเขามีอยู่ในที่เก็บ GitHub ซึ่งเป็นลิงก์ที่ให้ไว้ท้ายบทความในส่วน "ผลลัพธ์"3. ผลลัพธ์ นี่คือสิ่งที่เกิดขึ้นในที่สุด:

ภาพหน้าจอของเว็บไซต์นามบัตรที่ได้

ลิงก์ GitHub: https://github.com/vitalyswipe/tinymvc/zipball/v0.1

แต่ในเวอร์ชันนี้ฉันได้ร่างคลาสต่อไปนี้ (และประเภทที่เกี่ยวข้อง):

• Controller_Login ซึ่งสร้างมุมมองด้วยแบบฟอร์มสำหรับการเข้าสู่ระบบและรหัสผ่าน หลังจากกรอกขั้นตอนการตรวจสอบสิทธิ์แล้ว และหากสำเร็จ ผู้ใช้จะถูกเปลี่ยนเส้นทางไปยังแผงผู้ดูแลระบบ
• Contorller_Admin พร้อมการดำเนินการดัชนีที่ตรวจสอบว่าผู้ใช้เคยได้รับอนุญาตบนไซต์ในฐานะผู้ดูแลระบบมาก่อนหรือไม่ (หากเป็นเช่นนั้น มุมมองแผงผู้ดูแลระบบจะปรากฏขึ้น) และการดำเนินการออกจากระบบสำหรับการออกจากระบบ

การรับรองความถูกต้องและการอนุญาตเป็นหัวข้อที่แตกต่างกัน ดังนั้นจึงไม่ได้กล่าวถึงในที่นี้ แต่มีเพียงลิงก์ที่ให้ไว้ข้างต้นเท่านั้นที่ให้ไว้เพื่อให้คุณมีบางสิ่งที่จะเริ่มต้น4. สรุป รูปแบบ MVC ถูกใช้เป็นพื้นฐานทางสถาปัตยกรรมในหลายเฟรมเวิร์กและ CMS ที่สร้างขึ้นเพื่อให้สามารถพัฒนาคุณภาพที่สูงขึ้น โซลูชั่นที่ซับซ้อนสำหรับข้อมูลเพิ่มเติม ช่วงเวลาสั้น ๆ- สิ่งนี้เกิดขึ้นได้โดยการเพิ่มระดับของนามธรรม เนื่องจากมีขีดจำกัดความซับซ้อนของโครงสร้างที่สมองของมนุษย์สามารถใช้งานได้

แต่การใช้เฟรมเวิร์กเว็บเช่น Yii หรือ Kohana ที่ประกอบด้วยไฟล์หลายร้อยไฟล์ เมื่อพัฒนาแอปพลิเคชันเว็บแบบง่าย ๆ (เช่น ไซต์นามบัตร) ไม่แนะนำให้ใช้เสมอไป ตอนนี้เราสามารถสร้างโมเดล MVC ที่สวยงามได้ เพื่อไม่ให้โค้ด Php, Html, CSS และ JavaScript รวมอยู่ในไฟล์เดียว

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

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

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

แท็ก: เพิ่มแท็ก

รูปแบบ Model-View-Controller (MVC) ที่ค้นพบในช่วงปลายทศวรรษ 1970 เป็นรูปแบบการออกแบบสถาปัตยกรรม ซอฟต์แวร์ภารกิจหลักคือการแยกฟังก์ชั่นการทำงานกับข้อมูลออกจากการนำเสนอ ตามทฤษฎีแล้ว แอปพลิเคชัน MVC ที่ออกแบบมาอย่างดีจะช่วยให้นักพัฒนาส่วนหน้าและส่วนหลังไม่รบกวนพื้นที่รับผิดชอบของกันและกันในระหว่างการทำงาน กล่าวคือ นักพัฒนาส่วนหน้าไม่จำเป็นต้องรู้อะไรเกี่ยวกับ "ครัว" ของเพื่อนร่วมงานแบ็คเอนด์ของเขาและในทางกลับกัน

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

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

ทำความเข้าใจกับ MVC

ตามที่ได้กล่าวไปแล้ว ชื่อของรูปแบบมาจากคำย่อของคำสามคำ: Model (model), View (view) และ Controller (controller) โดยสรุป หลักการทำงานของรูปแบบสามารถแสดงได้ด้วยแผนภาพเดียว (สามารถพบได้ใน Wikipedia):

แผนภาพนี้แสดงให้เห็นอย่างชัดเจนถึงการไหลของข้อมูลในทิศทางเดียวในรูปแบบ และยังอธิบายบทบาทของแต่ละส่วนประกอบด้วย

แบบอย่าง

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

คุณลักษณะที่สำคัญอย่างยิ่งของโมเดลก็คือ ในทางเทคนิคแล้ว โมเดลไม่มีความรู้เกี่ยวกับสิ่งที่เกิดขึ้นกับข้อมูลในตัวควบคุมและมุมมอง โมเดลไม่ควรสร้างหรือรอคำขอใดๆ ไปยัง/จากส่วนประกอบรูปแบบอื่นๆ

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

ผลงาน

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

มีความเข้าใจผิดบางประการเกี่ยวกับวัตถุประสงค์ของมุมมอง โดยเฉพาะในหมู่นักพัฒนาเว็บที่เพิ่งเริ่มสร้างแอปพลิเคชันของตนโดยใช้ MVC กฎข้อหนึ่งที่ละเมิดบ่อยที่สุดคือวิวจะต้องไม่สื่อสารกับโมเดลในทางใดทางหนึ่ง และข้อมูลทั้งหมดที่ได้รับจากมุมมองจะต้องมาจากตัวควบคุมเท่านั้น ในทางปฏิบัติ นักพัฒนามักจะละเลยแนวคิดนี้ ซึ่งเป็นหัวใจสำคัญของรูปแบบ MVC บทความของ Fabio Cevasco แสดงให้เห็นถึงแนวทางที่น่าสับสนสำหรับ MVC โดยใช้ CakePHP ซึ่งเป็นหนึ่งในเฟรมเวิร์ก MVC ที่ไม่ได้มาตรฐานจำนวนมาก:

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

นอกจากนี้ ยังมีความเข้าใจผิดทั่วไปว่ามุมมองเป็นเพียงไฟล์เทมเพลต ดังที่ Tom Butler กล่าวไว้ ความเข้าใจผิดนี้มีขนาดใหญ่มากเนื่องจากการที่นักพัฒนาหลายคนเข้าใจโครงสร้าง MVC ผิดตั้งแต่แรก หลังจากนั้นพวกเขาก็เริ่มเท "ความรู้" นี้ไปยังนักพัฒนามือใหม่จำนวนมาก ในความเป็นจริง มุมมองเป็นมากกว่าเทมเพลต แต่เฟรมเวิร์กจำนวนมากที่สร้างขึ้นบนรูปแบบ MVC ได้บิดเบือนแนวคิดของมุมมองมากจนไม่มีใครสนใจว่าแอปพลิเคชันของพวกเขาถูกต้องในแง่ของรูปแบบ MVC หรือไม่

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

คอนโทรลเลอร์

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

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

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

MVC ใน PHP

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