เป็นไปได้หรือไม่ที่จะรวมแอพพลิเคชั่นเข้ากับกรอบอย่างหลวม ๆ ?

สมมติว่าฉันกำลังพัฒนาเว็บแอปพลิเคชัน ตัวเลือกแรกของฉันคือใช้ PHP กับ Fat-Free Framework (F3) และรูปแบบ MVC ปีหน้าฉันอาจตัดสินใจว่าอยากเปลี่ยนเป็น Zend Framework หรืออาจเป็น ASP.NET MVC ก็ได้ มันสมเหตุสมผลหรือไม่ที่จะลองและออกแบบแอปพลิเคชันของฉันในลักษณะที่มันเชื่อมโยงกับกรอบอย่างหลวม ๆ หรือเป็นกรอบที่สำคัญเกินไปที่จะทำให้สิ่งนี้เป็นจริงหรือไม่?

เหตุผลเดียวที่ฉันถามคือเพราะมันเกิดขึ้นในการสนทนากับเพียร์เมื่อเร็ว ๆ นี้ที่วิพากษ์วิจารณ์พายของฉันในความคิดที่ท้องฟ้าของการมีเพศสัมพันธ์อย่างหลวม ๆ ใบสมัครของฉันเพื่อ F3

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

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

ไม่สามารถทำได้

คุณสามารถออกแบบในแบบที่พกพาข้ามกรอบงานได้ MVC คือ MVC และมีหลักการเหมือนกันไม่ว่าจะใช้ภาษาหรือแพลตฟอร์มใด

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

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

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

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

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

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

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

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