อะไรคือความแตกต่างพื้นฐานระหว่าง MFC และ ATL?


110

สมมติว่าฉันกำลังเพียงใช้พวกเขาสำหรับ "ปกติ" โปรแกรม GUI (ไม่ COM ไม่มี ActiveX ไม่มีอะไรแฟนซี) สิ่งที่เป็นความแตกต่างพื้นฐานฉันจะเห็นระหว่าง ATL และ MFC เพื่อช่วยฉันคิดออกที่หนึ่งที่จะใช้งานหรือไม่


ฉันได้ทำการค้นหาบนเว็บแล้ว แต่ในที่สุดก็ไม่มีคำตอบใดที่ตอบคำถามของฉันได้เลย:

  • http://msdn.microsoft.com/en-us/library/bk8ytxz5(v=vs.80).aspx :

    • "ATL เป็นวิธีที่ง่ายและรวดเร็วในการสร้างคอมโพเนนต์ COM ใน C ++ และรักษาขนาดเล็กใช้ ATL เพื่อสร้างตัวควบคุมหากคุณไม่ต้องการฟังก์ชันในตัวทั้งหมดที่ MFC มีให้โดยอัตโนมัติ"

      ไม่ตอบคำถามของฉันจริงๆเพราะ:

      • ฉันไม่ได้ทำงานกับ COM

      • นี่หมายความว่า MFC ไม่เร็วหรือ? ทำไม / อย่างไร

    • "MFC ช่วยให้คุณสร้างแอปพลิเคชันเต็มรูปแบบตัวควบคุม ActiveX และเอกสารที่ใช้งานอยู่หากคุณได้สร้างตัวควบคุมด้วย MFC แล้วคุณอาจต้องการพัฒนาต่อใน MFC เมื่อสร้างตัวควบคุมใหม่ให้พิจารณาใช้ ATL หากคุณไม่ต้องการ ฟังก์ชันการทำงานในตัวทั้งหมดของ MFC "

      ยังไม่ตอบคำถามของฉันเนื่องจาก:

      • ฉันไม่รู้จริงๆว่า ActiveX คืออะไรในตอนแรก

      • ดูเหมือนว่า Microsoft จะไม่สนับสนุนการใช้ MFC แต่ฉันไม่สามารถหาสาเหตุได้

      • สิ่งที่ว่าเป็นของ MFC "ในตัวฟังก์ชั่น" ที่ ATL ไม่ให้?

    • โดยทั่วไปสิ่งนี้ไม่ตอบคำถามของฉันเพราะมันไม่ได้อธิบายถึงข้อเสียและเหตุผลเบื้องหลัง

เนื่องจากไม่ว่าทางตรงหรือทางอ้อมดูเหมือนว่าทุกอย่างจะเชื่อมโยงกลับไปยังหน้าที่แล้ว:

สิ่งที่ฉันสังเกตเห็นในขณะนี้ (ภายในสองสามวันที่ผ่านมาในขณะที่พยายามเรียนรู้ทั้งสองอย่าง):

  • ATL ขึ้นอยู่กับเทมเพลตหรือความหลากหลายของเวลาคอมไพล์
    • วิธีการ ATL มักจะไม่เสมือนจริงและมีแนวโน้มที่จะส่งคืนการอ้างอิง
  • MFC ขึ้นอยู่กับวิธีการเสมือนจริงหรือความหลากหลายในเวลาทำงาน
    • วิธีการ MFC มีแนวโน้มที่จะเสมือนจริงและมีแนวโน้มที่จะส่งกลับคำชี้

แต่ดูเหมือนจะไม่มีความแตกต่างทางสถาปัตยกรรมระหว่างกัน:

  • ทั้งสองใช้แผนที่ข้อความ ( BEGIN_MSG_MAPเทียบกับBEGIN_MESSAGE_MAP... เรื่องใหญ่)
  • ทั้งสองวิธีการรวม Win32 เป็นคลาส
  • ทั้งสองดูเหมือนจะมีคลาสที่คล้ายกันCWndกับCWindow

แต่ถ้าไม่มีความแตกต่างที่แท้จริงยกเว้นด้านเวลาคอมไพล์กับเวลาทำงานแล้วทำไมทั้งสองจึงมีอยู่? หนึ่งในนั้นไม่ควรเพียงพอหรือ

ฉันพลาดอะไรไปที่นี่?


3
ฉันอาจจะผิด แต่ฉันรู้ว่า MFC ต้องการรันไทม์ DLL ที่ค่อนข้างหนักในขณะที่ฉันคิดว่า ATL สร้างทั้งหมดเป็น exe เดียว ATL มีน้ำหนักเบากว่าโดยทั่วไป นอกจากนี้ตรวจสอบ WTL
Merlyn Morgan-Graham

@ เมอร์ลิน: ถูกต้อง แต่ทำไมมันถึงต้องการ DLL รันไทม์ที่หนักหน่วง? อะไรคือความแตกต่างพื้นฐานที่ทำให้เกิดสิ่งนี้?
user541686

1
ความแตกต่างที่เหมือนกันระหว่างการสืบทอดคลาสที่คอมไพล์ไว้ล่วงหน้าที่เชื่อมโยงจาก DLL และการสืบทอดเทมเพลตที่เชื่อมโยงโดยการรวมซอร์สโค้ด / การสร้างเทมเพลต โดยทั่วไปเทมเพลตจะเป็นไลบรารี "เฉพาะส่วนหัว" คำตอบของฉันไม่สมบูรณ์ดังนั้นในความคิดเห็น :) MFC ยังคงมีอยู่เนื่องจากการยอมรับอย่างมากและความเข้ากันได้ย้อนหลัง มิฉะนั้น MS จะโยนมันออกไปเมื่อพวกเขาสร้าง win32 wrapper ที่ใหม่กว่า พวกเขามักจะมีสัญญาการสนับสนุนที่ยาวนานเกี่ยวกับซอฟต์แวร์ของตน (แตกต่างกันไป แต่นานถึง 10 ปี) การสนับสนุนไม่สามารถใช้ร่วมกับการเลิกใช้งานได้
Merlyn Morgan-Graham

@ เมอลิน: สิ่งที่ฉันเข้าใจคือฉันไม่ควรใช้ MFC? "ฟังก์ชันพิเศษ" ที่พวกเขากล่าวถึงคืออะไร? ฉันต้องการหรือไม่
user541686

2
@ เมอลิน: เคยได้ยินเรื่อง ATL.DLL ไหม? เคยได้ยินคำว่า "Use MFC as Static Library" หรือไม่?
Ajay

คำตอบ:


179

ฉันคิดว่าคำตอบสำหรับคำถามของคุณส่วนใหญ่เป็นประวัติศาสตร์หากคุณมองย้อนกลับไปว่าห้องสมุดทั้งสองมีต้นกำเนิดและวิวัฒนาการอย่างไรตามกาลเวลา

คำตอบสั้น ๆ คือถ้าคุณไม่ได้ทำอะไรที่ "แฟนซี" ให้ใช้ ATL มันยอดเยี่ยมสำหรับอินเทอร์เฟซผู้ใช้ที่เรียบง่ายด้วย COM ที่ส่งเข้ามา

คำตอบยาว ๆ : MFC ถูกสร้างขึ้นในช่วงต้นทศวรรษที่ 90 เพื่อทดลองใช้ภาษาใหม่ที่เรียกว่า C ++ และนำไปใช้กับ Windows ทำให้ Office เป็นเหมือนฟีเจอร์พร้อมใช้งานสำหรับชุมชนการพัฒนาเมื่อระบบปฏิบัติการยังไม่มี

[แก้ไขการจัดแต่ง: ฉันไม่ได้ทำงานที่ Microsoft ดังนั้นฉันจึงไม่รู้ว่า Office ถูกสร้างขึ้นบน MFC หรือไม่ แต่ฉันคิดว่าคำตอบคือไม่ ย้อนกลับไปใน Win 3.1, Win 95 วันทีม Office UI จะคิดค้นการควบคุมใหม่บรรจุในไลบรารีจากนั้นทีม Windows และ MFC จะรวม Wrapper และ API เข้ากับการควบคุมเหล่านั้นด้วย dll ที่แจกจ่ายซ้ำได้ ฉันเดาว่ามีการทำงานร่วมกันและการแบ่งปันรหัสระหว่างทีมเหล่านั้นเล็กน้อย ในที่สุดการควบคุมเหล่านั้นจะทำให้เข้าสู่ระบบปฏิบัติการพื้นฐานในเซอร์วิสแพ็คหรือ Windows เวอร์ชันถัดไป รูปแบบนี้ดำเนินต่อไปโดยใช้ Office Ribbon ซึ่งถูกเพิ่มลงใน Windows เป็นส่วนประกอบเสริมหลังจากที่ Office จัดส่งและตอนนี้เป็นส่วนหนึ่งของ Windows OS]

ในเวลานั้นไลบรารีค่อนข้างเป็นแบบดั้งเดิมทั้งเนื่องจากภาษา C ++ และคอมไพเลอร์เป็นของใหม่และ Microsoft ก็สร้างมันขึ้นมาเมื่อเวลาผ่านไปเมื่อ Office พัฒนาขึ้น

เนื่องจากประวัติศาสตร์นี้ MFC:

  1. มีการออกแบบที่ค่อนข้างเกะกะ มันเริ่มต้นจากการเป็น light wrapper รอบ ๆ Windows API แต่เติบโตขึ้น มี 'คุณสมบัติ' เล็ก ๆ น้อย ๆ มากมายที่ต้องประดิษฐ์ขึ้นเนื่องจากคอมไพเลอร์และภาษาไม่รองรับ ไม่มีเทมเพลตพวกเขาคิดค้นคลาสสตริงประดิษฐ์คลาสรายการออกแบบการระบุประเภทเวลาทำงานของตนเองเป็นต้น
  2. ห่อหุ้มวิวัฒนาการของ Office และ Windows เป็นเวลา 20 ปีซึ่งรวมถึงสิ่งที่น่าเบื่อทั้งหมดที่คุณอาจไม่เคยใช้: อินเทอร์เฟซเอกสารเดียวและหลายเอกสาร DDE, COM, COM +, DCOM, การเชื่อมโยงและการฝังเอกสาร (เพื่อให้คุณสามารถฝังเอกสารคำใน แอปของคุณหากคุณต้องการ), ตัวควบคุม ActiveX (วิวัฒนาการของการฝังออบเจ็กต์สำหรับเว็บ!), การจัดเก็บเอกสารที่มีโครงสร้าง, การทำให้เป็นอนุกรมและการกำหนดเวอร์ชัน, การทำงานอัตโนมัติ (ตั้งแต่ต้นปี VBA) และแน่นอน MVC เวอร์ชันล่าสุดได้รับการสนับสนุนสำหรับการเชื่อมต่อหน้าต่างสไตล์ Visual Studio และ Office ribbon โดยพื้นฐานแล้วเทคโนโลยีทุกอย่างของ Redmond ในรอบ 20 ปีอยู่ที่นั่นที่ไหนสักแห่ง มันใหญ่มาก!
  3. มี gotchas ข้อบกพร่องวิธีแก้ปัญหาสมมติฐานการสนับสนุนสำหรับสิ่งต่างๆที่ยังคงอยู่ที่นั่นซึ่งคุณจะไม่เคยใช้และทำให้เกิดปัญหา คุณต้องคุ้นเคยอย่างใกล้ชิดกับการนำคลาสต่างๆมาใช้และวิธีที่พวกเขาโต้ตอบเพื่อใช้กับโปรเจ็กต์ขนาดพอเหมาะ การเจาะลึกซอร์สโค้ด MFC ระหว่างการดีบักเป็นเรื่องปกติ การค้นหาโน้ตเทคโนโลยีอายุ 15 ปีบนตัวชี้บางตัวที่เป็นโมฆะทำให้เกิดข้อขัดข้อง สมมติฐานเกี่ยวกับการเริ่มต้นของการฝังเอกสารโบราณอาจส่งผลกระทบต่อแอปพลิเคชันของคุณในรูปแบบแปลก ๆ ไม่มีสิ่งที่เรียกว่านามธรรมใน MFC คุณต้องทำงานกับมันเป็นเรื่องแปลกและภายในทุกวันมันไม่ได้ซ่อนอะไรเลย และอย่าให้ฉันเริ่มต้นด้วยตัวช่วยสร้างชั้นเรียน

ATL ถูกคิดค้นขึ้นเมื่อภาษา C ++ พัฒนาขึ้นและเทมเพลตก็มาถึง ATL เป็นการแสดงวิธีใช้เทมเพลตเพื่อหลีกเลี่ยงปัญหารันไทม์ของไลบรารี MFC:

  1. แผนที่ข้อความ: เนื่องจากเป็นเทมเพลตจึงมีการตรวจสอบประเภทและหากคุณทำผิดฟังก์ชันที่ถูกผูกไว้ก็จะไม่สร้างขึ้น ในแมปข้อความ MFC จะขึ้นอยู่กับแมโครและรันไทม์ที่ถูกผูกไว้ สิ่งนี้อาจทำให้เกิดข้อบกพร่องแปลก ๆ ข้อความที่ถูกส่งไปยังหน้าต่างที่ไม่ถูกต้องเกิดข้อผิดพลาดหากคุณมีฟังก์ชันหรือมาโครที่กำหนดไว้ไม่ถูกต้องหรือเพียงแค่ใช้งานไม่ได้เนื่องจากมีบางอย่างไม่ได้เชื่อมต่ออย่างถูกต้อง ยากกว่ามากในการแก้ไขข้อบกพร่องและทำลายได้ง่ายขึ้นโดยไม่สังเกตเห็น
  2. COM / Automation: คล้ายกับแมปข้อความโดยเดิม COM ถูกผูกไว้กับรันไทม์โดยใช้มาโครซึ่งต้องการการส่งข้อผิดพลาดจำนวนมากและทำให้เกิดปัญหาแปลก ๆ ATL ทำให้เทมเพลตเป็นไปตามรวบรวมเวลาที่ จำกัด และจัดการได้ง่ายกว่ามาก

[แก้ไขการปรุงแต่ง: ในขณะที่สร้าง ATL ขึ้นแผนที่ทางเทคนิคของ Microsoft เน้นที่ "การจัดการเอกสาร" เป็นหลัก Apple กำลังฆ่าพวกเขาในธุรกิจสิ่งพิมพ์บนเดสก์ท็อป Office 'การเชื่อมโยงและการฝังเอกสาร' เป็นองค์ประกอบหลักในการปรับปรุงคุณสมบัติ 'การจัดการเอกสาร' ของ Office เพื่อแข่งขันในพื้นที่นี้ COM เป็นเทคโนโลยีหลักที่คิดค้นขึ้นสำหรับการรวมแอปพลิเคชันและ Document Embedding API นั้นใช้ COM MFC ใช้งานยากสำหรับกรณีการใช้งานนี้ ATL เป็นทางออกที่ดีในการทำให้เทคโนโลยีเฉพาะนี้ง่ายขึ้นสำหรับบุคคลที่สามในการใช้ COM และใช้คุณสมบัติการฝังเอกสาร]

การปรับปรุงเล็กน้อยเหล่านี้ทำให้ ATL จัดการกับแอพพลิเคชั่นง่ายๆที่ไม่จำเป็นต้องใช้สำนักงานทั้งหมดเช่นคุณสมบัติของ MFC บางอย่างที่มี UI ที่เรียบง่ายและ Office Automation บางอย่างมีขนาดเล็กรวดเร็วรวบรวมเวลาได้มากช่วยให้คุณประหยัดเวลาและปวดหัวได้มาก MFC มีไลบรารีชั้นเรียนขนาดใหญ่ที่อาจไม่สะดวกและยากที่จะทำงานด้วย

น่าเสียดายที่ ATL หยุดนิ่ง มันมีเครื่องห่อสำหรับ windows API และการสนับสนุน COM และจากนั้นก็ไม่เคยไปไกลกว่านั้นจริงๆ เมื่อเว็บเปิดตัวเนื้อหาทั้งหมดนี้ถูกลืมไปแล้วว่าเป็นข่าวเก่า

[แก้ไขการปรุงแต่ง: ไมโครซอฟท์ตระหนักดีว่า "สิ่งที่อินเทอร์เน็ต" นี้จะใหญ่โต แผนที่ทางเทคนิคของพวกเขาเปลี่ยนไปอย่างมากเพื่อมุ่งเน้นไปที่ Internet Explorer, Windows Server, IIS, ASP, SQL Server, COM / DCOM ในเซิร์ฟเวอร์ธุรกรรมแบบกระจาย ดังนั้นการเชื่อมโยงและการฝังเอกสารจึงไม่มีความสำคัญสูงอีกต่อไป]

รอยเท้าขนาดใหญ่ของ MFC ทำให้ไม่สามารถถ่ายโอนข้อมูลได้ดังนั้นจึงยังคงพัฒนาอย่างช้าๆ เทมเพลตได้ถูกรวมกลับเข้าไปในไลบรารีเช่นเดียวกับการปรับปรุงภาษาและ API อื่น ๆ (ฉันไม่เคยได้ยิน WTL จนกระทั่งฉันเห็นคำถามนี้ :)

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

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


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


39
+1 ฉันหวังว่าฉันจะได้ +10 สิ่งนี้ ขอบคุณสำหรับคำอธิบายประวัติที่ยอดเยี่ยม - เขียนดีมากและให้ข้อมูล! :)
user541686

3
แค่อยากจะพูดถึง ... ฉันใช้ MFC มาสองสามวันแล้วเปลี่ยนมาใช้ ATL / WTL ซึ่งฉันใช้มาระยะหนึ่งแล้ว และมันยอดเยี่ยมมาก จะไม่ดู MFC อีกเลย
user541686

1
Microsoft จึงสร้างโปรแกรมใหม่โดยใช้ทั้งสองอย่างหรือไม่หรือตัดสินใจที่จะใช้โปรแกรมอื่น
The Muffin Man

1
ฉันคิดว่าฉันรู้ถึงความแตกต่าง.. แต่ไม่เคยเห็นคำอธิบายที่สวยงามและประณีตขนาดนี้.. ยกนิ้ว.. ขอบคุณตัน :)
shivi

1
คำตอบที่ดีที่สุดที่ฉันเคยอ่านในหัวข้อนี้ คุณควรจะทำบทความที่ออกมาจากมันรวมทั้ง WTL
แพท

20

ฉันได้รับการบอกเล่าจากหลาย ๆ คนที่ใช้ทั้งสองอย่างว่าประสบการณ์การเขียนโปรแกรมของพวกเขานั้นเจ็บปวดกับ ATL น้อยกว่ากับ MFC ไฟล์ปฏิบัติการที่คอมไพล์ของคุณจะมีขนาดเล็กลงมากเมื่อใช้ ATL

ฉันขอแนะนำให้คุณดูที่ WTLเนื่องจากสร้างจาก ATL

"ฟังก์ชันพิเศษ" ที่พวกเขากล่าวถึงคืออะไร? ฉันต้องการหรือไม่

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

แต่นี่คือบทความที่อธิบายคุณลักษณะบางอย่างใน MFC ที่ WTL / ATL ไม่รองรับโดยตรง

MFC ยังได้รับการพัฒนาจนถึงจุดที่รองรับคุณสมบัติที่ต้องการมากมายเช่น MAPI รองรับความต้องการโลโก้ Windows อื่น ๆ ซ็อกเก็ตเอกสาร (หากคุณชอบและ / หรือใช้รูปแบบนั้น) และไฟล์เอกสารแบบผสม WTL มีส่วนแบ่งของคุณสมบัติที่ยอดเยี่ยม แต่ MFC เป็นแชมป์คุณลักษณะที่ชัดเจน สภาพแวดล้อมทั้งสองสนับสนุนสถาปัตยกรรมหน้าต่างหลักแบบเฟรม (หน้าต่างเฟรมที่มีหน้าต่างมุมมองแยกต่างหาก) แอปพลิเคชัน SDI และ MDI หน้าต่างแยกแอปพลิเคชันแบบโต้ตอบและคลาสที่ใช้ COM ต่างๆสำหรับการสนับสนุน COM


3
คำตอบของเจย์มีจังหวะนี้ ทิ้งไว้สำหรับลิงก์ไปยังบทความที่อธิบายความแตกต่างบางประการ
Merlyn Morgan-Graham

9

ATL เป็นชุดของคลาสที่มีไว้เพื่อลดความซับซ้อนในการนำอ็อบเจ็กต์ COM ไปใช้งาน

คุณสามารถใช้งานได้โดยไม่ต้องใช้ MFC ที่งานของฉันเราใช้ ATL เพื่อแสดงอินเตอร์เฟส COM กับโค้ดการคำนวณ ไม่มี GUI ที่เกี่ยวข้องดังนั้นเราจึงสามารถเรียกรหัสการคำนวณนี้จากเช่น Excel VBA

ดูคู่มือ / บทช่วยสอน COM เพื่อดูสิ่งที่เป็นนามธรรม

MFC เป็นเพียงชุดของคลาส Wrapper GUI สำหรับ Win32 API ดูบทช่วยสอน Win32 API เพื่อดูว่ามีอะไรบ้าง


สามารถใช้ ATL ได้โดยไม่ต้องมี COM ใด ๆ หลายคลาสในนั้นไม่มีความสัมพันธ์กับ COM ซึ่งจะเด่นชัดยิ่งขึ้นเมื่อดู WTL
0xC0000022L

1
@ 0xC0000022L: ฉันไม่รู้CWindowImplและเพื่อน ๆ เมื่อฉันเขียนสิ่งนี้ ตอนนี้ฉันมีประสบการณ์กับ ATL มากขึ้นฉันสามารถลองเขียนคำตอบนี้ใหม่ได้ โดยเฉพาะอย่างยิ่ง ATL / WTL สามารถแทนที่ MFC ได้ทั้งหมด
Alexandre C.
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.