สำหรับโซลูชันที่ใช้ windows ขององค์กร. NET เป็นตัวเลือกที่ดีที่สุดในบางครั้ง Mono มีวิธีการดูอย่างไรโดยองค์กรที่ต้องใช้ Linux (หรือต้องการใช้ Linux) สมมติว่านักพัฒนาไม่มีปัญหาและพวกเขาคุ้นเคยกับ. NET / Mono และคู่แข่งอื่น ๆ ที่เป็นไปได้เช่น Java
บริษัท ขนาดกลาง / ใหญ่จะใช้ Mono บนเซิร์ฟเวอร์ของพวกเขาตรงข้ามกับเทคโนโลยีเช่น Java หรือไม่ คุณรู้จัก บริษัท ดังกล่าวบ้างไหม?
คำตอบ:
เราใช้มันใน บริษัท ขนาดใหญ่ที่ฉันทำงานอยู่ เราไม่ได้วางแผนตั้งแต่เริ่มโครงการ แต่มันก็เป็นเช่นนั้น
เรามีโครงการภายในที่เราพัฒนาใน. NET เมื่อเราเข้าสู่ UAT เจ้าของธุรกิจต้องการเปิดแอปให้กับลูกค้าบางคนรวมถึงพนักงานภายใน เซิร์ฟเวอร์ภายนอก (DMZ) ส่วนใหญ่ของเรานั้นใช้ Linux และเซิร์ฟเวอร์ Windows ที่อยู่ใน DMZ นั้นไม่เหมาะ (ใกล้กับความจุมากเกินไป) แทนที่จะซื้อฮาร์ดแวร์ใหม่มีคนแนะนำให้เรียกใช้แอปบน Mono เราใช้เวลาสองสามวันทำการทดสอบของเราเองแล้วปล่อยแอพไปยัง QA แล้วก็ UAT เราไม่มีปัญหา
หากเราได้รับข้อกำหนดเมื่อเริ่มโครงการเราอาจไม่ได้เลือกที่จะเขียนมันใน. NET แต่นี่เป็นผลลัพธ์ที่ดีอย่างหนึ่งต่อการเปลี่ยนแปลงข้อกำหนดที่ช้ามาก ๆ ตอนนี้เราค่อนข้างมั่นใจว่าถ้ามันเกิดขึ้นอีกครั้งเราสามารถปรับใช้กับ Mono ได้สำเร็จ (แม้ว่าฉันจะคิดว่าในที่สุดเราก็ต้องปรับแต่งโค้ดบางอย่างฉันคิดว่าเราเพิ่งโชคดี)
ฉันไม่ได้ใช้โมโนเชิงพาณิชย์ แต่ฉันใช้แบบส่วนตัวเพราะฉันทำงานใน บริษัท Windows แต่เป็นผู้ใช้ Linux แบบส่วนตัว (ดังนั้นฉันจึงสามารถนำสิ่งที่ฉันทำกลับมาใช้ใหม่ได้)
โดยรวมแล้วฉันเห็นด้วยกับ Miguel de Icaza ผู้กล่าวว่า:
- แอปพลิเคชั่น. NET 25% ทำงานนอกกรอบด้วยโมโน
- อีก 25% สามารถทำงานภายในหนึ่งวันหรือน้อยกว่า
- อีก 25% สามารถทำงานภายในหนึ่งสัปดาห์
- 25% สุดท้ายต้องการการเขียนแอปพลิเคชันใหม่อย่างสมบูรณ์ (WinForms / COM)
Mono ใช้งานได้ดี แต่มีปัญหา:
- VB.NET รองรับเฉพาะ. NET <= 2.0
- ไม่มีการรับรองความถูกต้องของ Windows
- WPF ไม่ได้ใช้งาน
- การสนับสนุน WCF ไม่สมบูรณ์
- Entity Framework ไม่ถูกนำไปใช้และไม่มีแผนที่จะใช้
- "ASP.NET Web Parts" ไม่ได้นำมาใช้
- ไม่มีการรองรับ COM-interop
- การเชื่อมต่อ Sybase สำหรับรุ่น 15.5 (ล่าสุด) ไม่ทำงาน
- ข้อบกพร่องและความไม่สมบูรณ์ในไลบรารีคลาส C # (เช่น XML เป็น buggy เป็น mono <2.6)
- การควบคุมเว็บเบราว์เซอร์ Linux ต้องใช้ GTK #
จากนั้นปัญหาเล็กน้อย:
- Windows Forms ทำงานได้ แต่แสดงผลไม่ถูกต้องเสมอไป
- MonoDevelop ไม่สามารถออกแบบฟอร์ม windows
- MonoDevelop การดีบักแบบ 'ก้าวผ่าน' ไม่ได้ผลจริงๆ
- บริการโมโนล่มหลังจาก 5 ชั่วโมง ...
สร้างสิ่งที่ฉันสามารถพูดได้:
- WebServices ทำงานอย่างยอดเยี่ยม
- หากคุณเรียกใช้ WebApplication จะทำงานได้ค่อนข้างดี (หากไม่ใช้ WebParts)
- ถ้าคุณเรียกใช้ WindowsForms มันจะไม่ดูดีเสมอไป (พูดน้อยที่สุด)
- ไม่มีสิ่งใดเทียบเท่ากับ Microsoft Reporting Service (FYIreporting เป็นสิ่งที่ใกล้เคียงที่สุด แต่ช้า, buggy และไม่สมบูรณ์มากรวมทั้งไม่มีกิจกรรมใด ๆ มานานกว่าหนึ่งปี)
- คุณจะประสบปัญหาหากคุณต้องการสร้างเอกสาร Word หรือ Excel
ถ้าคุณต้องการพัฒนา. NET บน Linux
- คุณสามารถพัฒนา ASP.NET ได้ที่นั่น (การดีบั๊ก & ขั้นตอนผ่านการทำงานแย่มาก)
- คุณไม่สามารถพัฒนา WinForms บน Linux ได้
- คุณต้องใช้ GTK # แทน WinForms
ในคำอื่น ๆ :
- Mono มีตำแหน่งในการใช้งานเว็บแอปพลิเคชันและ WebServices และ MailServers
- แต่มันไม่สามารถใช้งานแอพพลิเคชั่น WindowsForms ได้คุณต้องเขียนแอพพลิเคชั่นด้วย GTK #
- มันไม่มีโซลูชันการรายงานและรองรับรูปแบบไฟล์ MS (หรือไลบรารีที่ทำงาน)
แก้ไข (อัปเดตปี 2015):
ฉันต้องการเพิ่มในตอนนี้การดีบั๊ก 'ทีละขั้นตอน' ทำงานได้อย่างยอดเยี่ยมและคุณสามารถใช้ MonoDevelop เพื่อพัฒนาเว็บแอปพลิเคชั่นบน Linux แม้จะมีการพึ่งพา nuGet ปัญหาเกี่ยวกับไลบรารีของ Excel และ Word ก็หายไปด้วยและตอนนี้เอนทิตีของเฟรมเวิร์กก็เป็นโอเพ่นซอร์ส ส่วนที่เหลือค่อนข้างสวย "ตามสภาพ" (ไม่รู้ว่าบริการ mono คงที่หรือไม่ แต่ฉันหวังว่าจะเป็นเช่นนั้น)
สิ่งที่ได้รับการปรับปรุงเช่นกันคือตอนนี้คุณสามารถมีแพ็คเกจปัจจุบันสำหรับ distro ของคุณได้ซึ่งหมายความว่าคุณไม่จำเป็นต้องรอจนกระทั่งเดบิวต์รุ่นถัดไปพูดว่า Debian / Ubuntu จนกว่าคุณจะได้รับรุ่นโมโนเดี่ยวล่าสุด (โดยไม่ต้องรวบรวมเอง) ) นี่คือเวลาที่สำคัญที่ปลอดภัยกว่า
นอกจากนี้ด้วยการเปิดตัว Roslyn การสนับสนุน VB.NET ควรจะดีขึ้นมากในอนาคตอันใกล้
บริษัท ของฉันพัฒนาแอพพลิเคชั่นเดสก์ท็อปหลักส่วนใหญ่ - NET และเผยแพร่ Linux เวอร์ชันที่ทำงานบน Mono ดังนั้นฉันจะบอกว่าใช่มีที่สำหรับ Mono ในโซลูชันที่ใช้ Windows สำหรับองค์กร
เราทำแพคเกจ Mono พร้อมกับการติดตั้งแอปพลิเคชันของเราโดยไม่ต้องการให้ผู้ใช้ทำการติดตั้งแยกต่างหาก (และวิธีนี้เราควบคุมเวอร์ชันด้วย)
ฉันคิดว่าข้อกังวลหลักที่หลาย ๆ องค์กรน่าจะมีก็คือปัญหาด้านลิขสิทธิ์ระหว่าง Mono และ Microsoft ความเข้าใจของฉันคือว่าในขณะที่ Microsoft ได้ตกลงอย่างเป็นทางการแล้วว่า Mono สามารถใช้เทคโนโลยี core. NET ได้ แต่นอกนั้นรวมถึงสิ่งที่ใช้บ่อยๆเป็นพื้นที่สีเทาที่ถูกกฎหมายกับ Microsoft โดยระบุว่า บริษัท ไม่มีสถานะที่มั่นคง อื่น ๆ
เห็นได้ชัดว่าเป็นการเปิดความเป็นไปได้ที่พวกเขาจะต้องเสียค่าธรรมเนียมใบอนุญาตหรือฟ้องร้องการละเมิดสิทธิบัตร มันไม่น่าเป็นไปได้ที่จะเกิดขึ้นจากพฤติกรรมที่พวกเขาทำในตอนนี้ แต่ บริษัท ส่วนใหญ่ไม่ชอบความไม่แน่นอนเช่นนั้นโดยเฉพาะเมื่อมันมาพร้อมกับหนี้สินและค่าใช้จ่ายที่อาจเกิดขึ้น
ฉันไม่คิดว่าจะมีพื้นที่ว่างสำหรับ Mono ที่นั่น:
Java เป็นแพลตฟอร์มที่สร้างไว้แล้วบน Linux ด้วยชุมชนขนาดใหญ่และห้องสมุดและเครื่องมือคุณภาพระดับองค์กรมากมายทั้งในเชิงพาณิชย์และโอเพ่นซอร์ส ฉันไม่เห็นเหตุผลใด ๆ ที่จะเลือก Mono บน Java เมื่อเริ่มต้นโครงการใหม่ที่กำหนดเป้าหมายเป็น Linux (หรือ Mac) ยกเว้นกรณีที่มีเหตุการณ์เฉพาะ (ดูคำตอบของ Walter)
ก่อนที่จะใช้โมโนเราต้องแน่ใจว่าไม่มี hardcoded '\' สำหรับสตริงของเส้นทาง (ใช้ Path.Combine ()) หรือคำนำหน้า "COM" (เพียงแค่ยอมรับสตริงแทนจำนวนเต็ม) สำหรับพอร์ตอนุกรมที่อยู่ในโปรแกรม
อะไรทำงานได้ดี:
ปัญหาที่พบ:
เป็นการดีกว่าที่จะใช้โมโนภายใน (เช่นระบบ ERP) เป็นสภาพแวดล้อมที่มีการควบคุม
Mono เป็นทางเลือกที่ยอดเยี่ยมหากคุณมีรหัส. NET ที่ต้องทำงานบนสภาพแวดล้อมข้ามแพลตฟอร์ม โมโนถูกนำมาใช้อย่างกว้างขวางในโลกธุรกิจโดยเฉพาะเพื่อแก้ไขปัญหานี้
ฉันจะโต้แย้งกับการมีอยู่ของ Mono เป็นข้ออ้างสำหรับการเริ่มต้นโครงการกับ. NET ที่คุณรู้ว่าจะต้องข้ามแพลตฟอร์ม เหตุผลของเรื่องนี้คือความล่าช้าระหว่างความทันสมัยกับ. NET กับความเร็วในการพัฒนาของโมโน
ในทางตรงกันข้ามถ้าคุณไม่ตั้งใจที่จะใช้โมโนในโครงการในอนาคตผมจะเตือนคุณสามารถกำหนดเป้าหมายกรอบโมโนและทำงานบน .NET เป็นทางเลือกรองตั้งแต่โมโนเป็นส่วนใหญ่ส่วนหนึ่งของการทำงาน .NET เต็ม