คำถามนี้เน้นที่การแยกข้อดีและข้อเสียของการใช้ Framework บนเว็บเช่น Cake PHP, Zend, jQuery, ASP.NET) คำถามนี้เป็นคำถามสมบูรณ์ไม่เชื่อเรื่องพระเจ้าภาษา ผมขอเริ่มด้วยแนวคิด"ยืนอยู่บนไหล่ของไจแอนต์ "

ข้อดี:

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

ข้อเสีย:

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

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

นี่คือบรรทัดล่าง: มันอาจเป็นเรื่องยากที่จะใช้คุณสมบัตินอกกรอบการกำหนดค่า

ลองทำข้อสมมติฐานนี้โดยสมมุติ

การทำความเข้าใจที่หายไป - โดยอาศัยคุณสมบัติของกรอบงานที่นักพัฒนากำลังตกอยู่ในอันตรายจากการสูญเสียความเข้าใจในการทำงานของสิ่งต่าง ๆ (ใต้ฝากระโปรง)

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

เชื่อหรือไม่ว่าคุณจะทำผิดพลาดโดยใช้กรอบ คุณจะต้องดีบักลงไปที่ระดับต่ำสุดของ HTTP เพื่อทำความเข้าใจกับสิ่งที่คุณทำผิด

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

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

นี่ทำให้รู้สึกมีค่าเล็กน้อย

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

ที่สอง การใช้สิ่งต่าง ๆ นอกกรอบเป็นงานที่ต้องทำอยู่เสมอเพราะ - อะแฮ่ม - การใช้สิ่งใดนอกกรอบมักจะเป็นงานจำนวนมาก มันไม่มีส่วนเกี่ยวข้องกับเวลาที่ใช้ในการเรียนรู้และกำหนดกรอบงาน การนำสิ่งที่อยู่นอกกรอบมาใช้นั้นทำได้ยาก

tramlines สำหรับนักพัฒนา - คุณ (ผู้พัฒนา) ต้องทำสิ่งต่าง ๆ ในแบบที่นักพัฒนา [framework] ต้องการให้คุณทำ

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

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

อะไร? สิ่งนี้ไม่เกี่ยวข้องกับกรอบงาน การฉ้อโกงเป็นการฉ้อโกงโดยไม่คำนึงถึงเครื่องมือที่ใช้

คอนดิชั่น: การสนับสนุนที่เป็นไปได้ลดลง / การสูญเสียความนิยม

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

Pro: รหัสสำหรับธุรกิจ

• กรอบงานช่วยให้คุณไม่ต้องกังวลกับงานเสี้ยงฮึดฮัดแสดงความไม่พอใจและมุ่งเน้นไปที่รหัสที่นำคุณค่าโดยตรงกับธุรกิจ
• บางครั้งการอัพเกรดเฟรมเวิร์ก (เพียงแค่ใช้งานได้) จะช่วยให้คุณสามารถส่งมอบคุณสมบัติใหม่ให้กับผู้ใช้ของคุณในทางปฏิบัติ "ได้ฟรี" โดยเฉพาะอย่างยิ่งกับเฟรมเวิร์กที่มาพร้อมกับคอนโทรลแบบกำหนดเอง (เช่นกริดที่เวอร์ชันใหม่อาจมีการค้นหา / ตัวกรองบางประเภท)

ข้อดี

• เวลาในการพัฒนาที่เร็วขึ้น
• ข้อบกพร่องน้อยลง
• การพัฒนาร่วมกันเร็วขึ้น
• สนับสนุนห้องสมุด
• ปฏิสัมพันธ์ DB ง่าย

ข้อเสีย

• "บรรจุในกล่อง" เข้ากับกรอบ
• มักจะไม่ยืดหยุ่นเมื่อต้องการขยายหรือปรับเปลี่ยนพฤติกรรมหลัก
• "ข้อผิดพลาดของการลงโทษ" - ข้อผิดพลาดที่เกิดขึ้นจากแกนกลางหรือสถาปัตยกรรมพื้นฐานที่ไม่มีการย้อนกลับที่ดีไปยังจุดกำเนิด ตัวอย่างที่สมบูรณ์แบบคือข้อผิดพลาดของสปริงเมื่อใช้ Grails

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

สองสิ่งที่อยู่ในใจคือ ...

ข้อดี

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

ข้อเสีย

• สูญเสียการสนับสนุน มาถึงใจที่นี่คือ Symfony 1.4 ฉันจินตนาการว่า Symfony จะให้การสนับสนุน 1.4 มาระยะหนึ่งแล้ว แต่เมื่อรู้ว่า 2.0 ไม่รองรับการใช้งานย้อนหลัง 1.4 ดูเหมือนว่าจะเป็นจุดจบของการสนับสนุนในปีต่อ ๆ ไป
• ค่าใช้จ่าย; ด้วยการใช้เฟรมเวิร์กคุณกำลังรันหลายพันบรรทัดที่อาจไม่สามารถใช้กับแอปพลิเคชันเฉพาะของคุณ แต่ใช้กับผู้อื่น บางคนคิดว่านี่เป็นการแลกเปลี่ยนที่สมเหตุสมผลและบางคนเลือกที่จะเขียนโค้ดจากพื้นฐานเพื่อประสิทธิภาพ
• การใช้เฟรมเวิร์กผิดสำหรับความต้องการเฉพาะของคุณ กรอบงานทั้งหมดไม่ได้ถูกสร้างขึ้นอย่างเท่าเทียมกัน

ทุกอย่างขึ้นอยู่กับกรอบที่คุณใช้

ถ้าคุณใช้ ASP.NET คุณจะเสียเปรียบ: มันเป็นนามธรรมที่ดีที่สุดและที่แย่ที่สุดทำให้มันเจ็บปวดในการทำสิ่งต่าง ๆ ที่ไม่สำคัญในกรอบอื่น ๆ ที่ไม่ซ่อนความจริงที่ว่าคุณเป็น ทำงานบนเว็บ

ASP.NET MVC พยายามแก้ไขปัญหานั้นและมันก็ทำได้ดี

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

ฉันต้องการเพิ่มคะแนน

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

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

ข้อดี:

• เมื่อคุณใช้กรอบงานอย่างสม่ำเสมอเวลาเรียนรู้สำหรับโครงการจะลดลงสำหรับผู้ที่ทำงานในโครงการของคุณแล้ว
• การพัฒนาที่เร็วขึ้นของคุณเอง
• พัฒนาศักยภาพของคุณเอง

ฉันพูดจากประสบการณ์ส่วนตัวในช่วง 13 ปีที่ผ่านมา ใน บริษัท ของฉันเราใช้เสาหลังจากโค้งสั้น ๆ มันยอดเยี่ยมมาก ในครั้งต่อไปของเราเราใช้สถาปัตยกรรมที่ส่วนใหญ่ทึบแสงค่อนข้างคล้ายเสา แต่โตขึ้นเราสามารถขยายได้ แต่รหัสหลักเป็นเพียงขวด และอื่น ๆ ใน 3 ปีที่ผ่านมาทำงานใน บริษัท ขนาดเล็ก (จำนวน dev <30) และมันเป็น jsps, servlets และ ejbs ทั้งหมดของเราเอง การดูลูกค้าหลายรายและการทำซ้ำ jsps ในปี 2012 คือการสร้างตัวกรอง j2ee ที่เลียนแบบ struts2 20% ทำไมไม่ใช้ stuts 2 ฉันหวังว่าเราจะมี แต่: ไม่สามารถผ่านหัวหน้าสถาปนิกของเราได้ ประสบการณ์หรือเวลาไม่เพียงพอ

ดังนั้นเราจึงมี intercepters jsps ทั่วไปที่มินิเฟรมเวิร์กของเราใช้ ตอนนี้เมื่อฉันมีเวลาผ่านหนังสือ 2 เล่มฉันเห็นว่าเราพลาดไปมาก!

เราใช้อัลกอริธึมและแคชและ UI ที่ยอดเยี่ยม แต่เสียเวลาไปหลายชั่วโมงและใช้โค้ดจำนวนมากที่เรามีแผน 3 ปีในการเกษียณ