WinForms மாற்றுகள் ஒப்பீடு

Majorsilence.Forms vs .NET MAUI, Avalonia, Uno Platform, Eto.Forms, WPF மற்றும் Wine — ஒவ்வொன்றும் ஏற்கனவே உள்ள WinForms குறியீட்டுத் தளத்திடம் உண்மையில் என்ன கேட்கிறது.

இந்தப் பக்கம் ஒரு மொழிபெயர்ப்பு. ஆங்கிலப் பதிப்புடன் வேறுபாடு இருந்தால், ஆங்கிலப் பதிப்பே சரியானது. English

உங்களிடம் இயங்கும் ஒரு WinForms பயன்பாடு இருந்து, அது macOS அல்லது Linux-இல் தேவைப்பட்டால், உண்மையான கேள்வி “எந்த UI framework சிறந்தது” என்பதல்ல — “என் ஏற்கனவே உள்ள குறியீட்டில் எவ்வளவு தப்பிப் பிழைக்கும்?” என்பதுதான். கீழே உள்ள ஒவ்வொரு தேர்வும் நல்ல framework தான். அவை உங்கள் குறியீட்டுத் தளத்திடம் மிகவும் வேறுபட்ட அளவுகளைக் கேட்கின்றன, அவ்வளவுதான்.

சுருக்கமாக

Majorsilence.Forms இவற்றில் பலவற்றின் மீது கட்டப்பட்டது

இது பொதுவாகத் தவறாகப் புரிந்துகொள்ளப்படுவதால் தெளிவாகச் சொல்வது நல்லது: Majorsilence.Forms, Avalonia, Uno Platform அல்லது GTK உடன் போட்டியிடவில்லை. அது அவற்றைப் பயன்படுத்துகிறது. ஒவ்வொரு கட்டுப்பாடும் Majorsilence.Forms தானே SkiaSharp மூலம் வரைகிறது; அடியில் உள்ள ஹோஸ்ட் — இயல்புநிலையாக Avalonia, அல்லது Uno, அல்லது gir.core வழியாக ஒரு உண்மையான GTK 4 சாளரம் — சாளரத்தை உருவாக்கி, message loop-ஐ இயக்கி, Skia surface-ஐக் காட்டுகிறது. Windows-இல் அதே கட்டுப்பாடுகளை உண்மையான System.Windows.Forms அல்லது WPF சாளரங்களும் ஹோஸ்ட் செய்யலாம்; அதுவே படிப்படியான, இருந்த இடத்திலேயே நடக்கும் இடம்பெயர்த்தலைச் சாத்தியமாக்குகிறது. தளப் பின்தளங்கள் பாருங்கள்.

எனவே தேர்வு “Majorsilence.Forms அல்லது Avalonia” அல்ல. அது இதுதான்: Avalonia-வின் XAML-ஐ நேரடியாக எழுதுகிறீர்களா, அல்லது WinForms-ஐயே தொடர்ந்து எழுதி Avalonia-வை (அல்லது GTK 4, அல்லது Uno-வை) அடிக்கட்டமைப்பாக இருக்க விடுகிறீர்களா?

ஒவ்வொரு தேர்வாக

.NET MAUI

Xamarin.Forms-க்கு Microsoft-இன் அதிகாரப்பூர்வ பல்தள வாரிசு; பெரும்பாலான தேடல் முடிவுகள் தரும் பதிலும் இதுதான். புதிய மொபைல்-மற்றும்-desktop பயன்பாட்டுக்கு இது வலுவான தேர்வு.

ஏற்கனவே உள்ள WinForms LOB பயன்பாட்டுக்கு இது பொதுவாக மிகக் கடினமான பாதை: அதிகாரப்பூர்வ Linux ஆதரவு இல்லை, கட்டுப்பாட்டுத் தொகுப்பு மொபைல்-முதன்மையானது (DataGridView-க்குச் சமமானது இல்லை, வேறுபட்ட சாளர மற்றும் உரையாடல் சாளர மாதிரி), ஒவ்வொரு திரையும் உங்கள் WinForms குறியீட்டில் நிச்சயமாக இல்லாத ஒரு view-model அடுக்குடன் XAML-இல் மீண்டும் கட்டப்படுகிறது. *.Designer.cs கோப்புகளை அர்த்தமுள்ள வகையில் மீண்டும் பயன்படுத்த முடியாது.

Avalonia

முதிர்ந்த, உண்மையிலேயே பல்தளமான XAML framework — desktop, மொபைல் மற்றும் WebAssembly — சிறந்த Linux ஆதரவு மற்றும் Skia renderer உடன். நவீன XAML அடுக்கு வேண்டும், UI அடுக்கை மீண்டும் எழுதத் தயார் என்றால், இதுவே மிக வலுவான பொதுவான பதில்; Majorsilence.Forms இயங்கும் இயல்புநிலை ஹோஸ்டும் இதுதான்.

கவனிக்கவும்: Avalonia-வின் வணிகத் தயாரிப்பான XPF என்பது WPF-க்கான இணக்க அடுக்கு, WinForms-க்கு அல்ல; அது ஒரு System.Windows.Forms குறியீட்டுத் தளத்துக்கு உதவாது.

Uno Platform

WinUI/UWP XAML API-ஐ desktop, மொபைல் மற்றும் WebAssembly முழுவதும் செயல்படுத்துகிறது; மிகப் பரந்த எட்டல் மற்றும் வலுவான கருவிகளுடன். Avalonia போன்றதே முடிவின் வடிவமும்: சிறந்த இலக்கு, WinForms-இலிருந்து முழு UI மீண்டும் எழுதுதல். உங்கள் நிறுவனம் ஏற்கனவே இதில் முதலீடு செய்திருந்தால், இது Majorsilence.Forms பின்தளமாகவும் கிடைக்கிறது.

Eto.Forms

இந்தத் திட்டத்துக்கு வெளியே உணர்வில் இதற்கு மிக நெருக்கமானது: XAML-க்குப் பதிலாக forms-மற்றும்-கட்டுப்பாடுகள் API கொண்ட, ஒவ்வொரு தளத்தின் native widgets-உடன் (Windows-இல் WinForms, macOS-இல் Cocoa, Linux-இல் GTK) இணைக்கும் ஒரு பல்தள .NET UI நூலகம். ஒவ்வொரு OS-க்கும் native தோற்றம் உண்மையான நன்மை.

ஆனால் அதன் API அதற்கே உரியது — Eto.Forms.Form என்பது System.Windows.Forms.Form அல்ல, layout ஆயத்தொலைவு/anchor-அடிப்படையில் அல்லாமல் container-அடிப்படையிலானது, ஏற்கனவே உள்ள designer கோப்புகளுக்கு வழி இல்லை. பழக்கமான பாணியில் நீங்கள் மீண்டும் எழுதுகிறீர்கள். Majorsilence.Forms-க்கு இப்போது அதற்கென ஒரு GTK 4 பின்தளம் இருந்தாலும் அந்த ஒப்பீடு இன்னும் பொருந்தும்: Eto தனது கட்டுப்பாடுகளை GTK widgets மீது பொருத்துகிறது; Majorsilence.Forms GTK சாளரத்தையும் உள்ளீட்டு loop-ஐயும் ஹோஸ்டாக மட்டுமே பயன்படுத்தி, தனது சொந்த WinForms-வடிவக் கட்டுப்பாடுகளைத் தொடர்ந்து தானே வரைகிறது.

Mono-வின் System.Windows.Forms

Mono ஒரு WinForms மறுசெயலாக்கத்தை வெளியிட்டது; அதனால்தான் பழைய forum உரையாடல்களில் “WinForms Linux-இல் வேலை செய்கிறது” என்று காணப்படுகிறது. அது .NET Framework காலத்தை இலக்காகக் கொண்டது, நவீன .NET-க்கு ஒருபோதும் கொண்டு செல்லப்படவில்லை, இன்று புதிய port-க்கு ஏற்ற இலக்கு அல்ல.

Wine

Wine உங்கள் மாற்றப்படாத Windows binary-ஐ Linux மற்றும் macOS-இல் இயக்குகிறது. உங்கள் குறியீட்டில் எதுவும் மாறுவதில்லை; அது உண்மையிலேயே கவர்ச்சிகரமானது — அதை ஆதரிக்க வேண்டி வரும் வரை: நீங்கள் ஒரு Windows பயன்பாட்டையும் ஓர் இணக்க runtime-ஐயும் சேர்த்து வழங்குகிறீர்கள், Wine-இன் Win32/GDI+ உள்ளடக்கம் எவ்வளவோ அதைச் சுமக்கிறீர்கள், ஹோஸ்ட் OS உடனான ஒருங்கிணைப்பு தோராயமானது, installers மற்றும் updates சிக்கலாகின்றன. அது ஒரு deployment சுற்றுவழி, தள உத்தி அல்ல.

WPF-இலேயே இருத்தல்

WPF ஒரு நல்ல framework, WinForms-இலிருந்து கருத்தியல் ரீதியாகச் சிறிய படி மட்டுமே, ஆனால் அது Windows-மட்டும். அது “UI-ஐ நவீனமாக்கு” என்பதைத் தீர்க்கிறது; “macOS மற்றும் Linux-இல் இயக்கு” என்பதைத் தீர்க்கவில்லை. (உங்களிடம் ஏற்கனவே ஒரு WPF shell இருந்து அதற்குள் பல்தளத் திரைகள் வேண்டுமென்றால், சரியாக அதற்கே Majorsilence.Forms-இல் ஒரு WPF ஹோஸ்ட் பின்தளம் உள்ளது — ஆனால் WPF shell தானே Windows-இலேயே இருக்கும்.)

Majorsilence.Forms எப்போது சரியான பதில்

• உங்களிடம் கணிசமான WinForms குறியீட்டுத் தளம் உள்ளது — குறிப்பாகப் பல படிவங்கள் கொண்ட வணிக (LOB) பயன்பாடு — அங்கே வணிகத் தர்க்கமும் UX-உம் சொத்து, மீண்டும் எழுதுவதன் அபாயமே பிரச்சினை.
• உங்கள் அணியின் திறன்கள் WinForms-இல் உள்ளன, XAML/MVVM மறுபயிற்சிச் சுழற்சி ஒரு உண்மையான செலவு.
• ஒரே குறியீட்டுத் தளத்திலிருந்து Windows, macOS மற்றும் Linux தேவை; உலாவியும் மொபைலும் பின்னர் ஒரு தேர்வாக.
• port செய்வதற்காக எல்லாவற்றையும் நிறுத்த முடியாது. Majorsilence.Forms.WinForms மற்றும் .Wpf பின்தளங்கள் பல்தளக் கட்டுப்பாடுகளை உங்கள் ஏற்கனவே உள்ள Windows பயன்பாட்டுக்குள், ஒரு நேரத்தில் ஒரு கட்டுப்பாடு அல்லது படிவமாக ஹோஸ்ட் செய்கின்றன — அவை net48-ஐ இலக்காகக் கொள்வதால், நீங்கள் நவீன .NET-க்கு மாறுவதற்கு முன்பே .NET Framework 4.8 பயன்பாட்டிலிருந்தே இது வேலை செய்கிறது. அதே CSS தீம் port செய்யப்பட்டவற்றுடன் உண்மையான WinForms கட்டுப்பாடுகளையும் மீண்டும் அலங்கரிக்க முடியும் (Majorsilence.Forms.Theming.WinForms), எனவே கலப்புப் பயன்பாடு ஒரே பயன்பாடாகத் தோன்றும்.
• பீட்டா நிலை இணக்க அடுக்கை ஏற்றுக்கொண்டு பதிப்பை நிலைப்படுத்த உங்களால் முடியும்.

எப்போது அது சரியான பதில் அல்ல

• புதிதாகத் தொடங்கும் திட்டம், WinForms குறியீடும் இல்லை, WinForms அணியும் இல்லை. Avalonia அல்லது Uno-வை நேரடியாக எழுதுங்கள்; நடுவில் இணக்க அடுக்கு இல்லாமல் முதிர்ந்த XAML அடுக்கு கிடைக்கும்.
• மொபைல்-முதன்மை. MAUI, Avalonia அல்லது Uno இன்று தொலைபேசிகளைச் சரியாக இலக்காகக் கொள்கின்றன. Majorsilence.Forms-இன் Android ஆதரவுக்கு உண்மைச் சாதனத்தில் முதற்கட்டச் சோதனை மட்டுமே நடந்துள்ளது, iOS-க்கு CI simulator smoke check மட்டுமே — இரண்டும் ஆரம்ப நிலை — மேலும் framework இப்போது வழங்கும் தொலைபேசி-பாணி StackPanel/Card/NavigationHost கட்டுப்பாடுகள் இருந்தாலும், ஆயத்தொலைவால் நிலைநிறுத்தப்பட்ட desktop படிவம் எப்படியும் தொலைபேசிக்கு மோசமான UI.
• உங்கள் பயன்பாடு Win32-இல் ஆழமாக மூழ்கியுள்ளது. அதிகமான WndProc, Control.Handle P/Invoke அல்லது custom Win32 கட்டுப்பாடுகள் உண்மையான உழைப்பின்றி இந்த port-களில் எதிலும் — இதையும் சேர்த்து — தப்பிப் பிழைக்காது.
• Windows-இல் native WinForms உடன் பிக்சல்-சமமான ஒற்றுமை தேவை. கட்டுப்பாடுகள் Skia மூலம் வரையப்பட்டு CSS மூலம் தீம் செய்யப்படுகின்றன, ஒவ்வொரு OS-இன் native widgets-ஐப் பொருத்துவதற்குப் பதிலாகத் தளங்களிடையே சீராக. (port செய்யப்பட்ட பயன்பாடு தனது எழுத்துருவை அமைத்தவுடன் push buttons மற்றும் check/radio glyphs Windows 11-பாணித் தோற்றத்தைப் பெறுகின்றன, ஆனால் அது கலப்புப் பயன்பாடுகளுக்கான ஒரு வசதி மட்டுமே, ஒற்றுமைக்கான உத்தரவாதம் அல்ல.)

அடுத்து

• பல்தள WinForms — இணக்க அடுக்கு எப்படி வேலை செய்கிறது, அதன் விலை என்ன.
• ஏற்கனவே உள்ள WinForms பயன்பாட்டை இடம்பெயர்த்தல் — தானியக்க மீண்டும் எழுதுதல்.
• இணக்க அட்டவணை — நீங்கள் உறுதிசெய்வதற்கு முன், கட்டுப்பாடு வாரியான உள்ளடக்கம்.