W Co byś wybrał dla swojego projektu między .NET i Java w tym momencie? Mówię, że zastanowiłbym się: „Czy zawsze wdrażasz system Windows?” najważniejszą decyzją techniczną, którą należy podjąć w nowym projekcie internetowym, a jeśli odpowiedź brzmi „nie”, poleciłbym Javę zamiast .NET.
Bardzo częstym kontrargumentem jest to, że „jeśli kiedykolwiek chcemy uruchomić na Linux / OS X / Cokolwiek, po prostu uruchomimy Mono” 1 , co jest bardzo przekonującym argumentem na pozór, ale nie zgadzam się na kilka powody.
- OpenJDK i wszyscy dostawcy JVM dostarczyli oficjalną Sun TCK, zapewniając prawidłowe działanie. Nie wiem, czy Mono przechodzi przez Microsoft TCK.
- Mono śledzi wydania .NET. Jaki poziom .NET jest obecnie w pełni obsługiwany?
- Czy wszystkie elementy GUI (WinForm?) Działają poprawnie w Mono?
- Firmy mogą nie chcieć polegać na ramach Open Source jako oficjalnym planie B.
Wiem, że dzięki nowemu zarządzaniu Javą przez Oracle przyszłość jest niebezpieczna, ale np. IBM zapewnia JDK dla wielu platform , w tym Linux. Po prostu nie są to źródła otwarte.
Więc w jakich okolicznościach Mono jest prawidłową strategią biznesową dla aplikacji .NET?
1 Mark H streścił to w następujący sposób : „Jeśli twierdzenie jest takie, że „ Mam aplikację Windows napisaną w .NET, powinien działać na mono ” , to nie jest to uzasadnione roszczenie - ale Mono dołożyło starań, aby przenieść takie aplikacje prostsze ”.
Odpowiedzi:
Odpowiedź Sparkiego to zrozumiała , pozwólcie, że trochę uzupełnię.
„.NET jest wieloplatformowy” to zbyt wieloznaczne stwierdzenie, ponieważ zarówno środowisko, jak i świat, dla którego został stworzony, zmieniły się i ewoluowały.
Krótka odpowiedź brzmi:
Podstawowy silnik, który zasila platformę .NET i jej pochodne, Common Language Infrastructure Standard, jest wieloplatformowy i jeśli chcesz, aby Twój kod trafiał na wiele platform, musisz zaplanować użycie odpowiednich interfejsów API na właściwej platformie, aby dostarczyć najlepsze wrażenia na każdej platformie.
Rodzina CLI nie wypróbowała metody „Napisz raz, uruchom gdziekolwiek”, ponieważ różnice między telefonem a komputerem mainframe są zbyt duże. Zamiast tego powstał wszechstronny interfejs API i funkcje wykonawcze, które są specyficzne dla platformy, aby dać programistom odpowiednie narzędzia do tworzenia doskonałych doświadczeń na każdej platformie.
Pomyśl o tym: programiści nie atakują już komputerów z systemem Windows ani serwerów Unix. Świat, bardziej niż kiedykolwiek, otoczony jest fascynującymi platformami od komputerów osobistych, konsol do gier, potężnych telefonów, dekoderów, dużych serwerów i rozproszonych klastrów maszyn. Jeden rozmiar pasujący do wszystkich platform po prostu czułby się rozdęty na małych urządzeniach, a na dużych systemach czułby się słabo .
Produkt Microsoft .NET Framework nie jest wieloplatformowy, działa tylko w systemie Windows. Istnieją odmiany Microsoft .NET Framework firmy Microsoft, które działają na innych systemach, takich jak Windows Phone 7, XBox360 i przeglądarki za pośrednictwem Silverlight, ale wszystkie są nieco innymi profilami.
Dziś możesz kierować reklamy do wszystkich głównych systemów operacyjnych, telefonów, urządzeń mobilnych, systemów wbudowanych i serwerów za pomocą technologii opartych na .NET. Oto lista, która pokazuje implementację interfejsu CLI w każdym przypadku (ta lista nie jest wyczerpująca, ale powinna obejmować 99% przypadków):
W zależności od potrzeb powyższe może być wystarczające lub nie. Prawie nie dostaniesz tego samego kodu źródłowego do uruchomienia wszędzie. Na przykład kod XNA nie będzie działał na każdym pulpicie, podczas gdy oprogramowanie .NET Desktop nie będzie działać na XNA lub telefonie. Zwykle musisz wprowadzić zmiany w kodzie, aby działały w innych profilach .NET Framework. Oto niektóre profile, które znam:
Tak więc każdy z tych profili jest nieco inny i nie jest to zła rzecz. Każdy profil został zaprojektowany w taki sposób, aby pasował do platformy hosta i udostępniał interfejsy API, które mają sens, i usuwa te, które nie mają sensu.
Na przykład interfejsy API Silverlight do sterowania przeglądarką hosta nie mają sensu w telefonie. A moduły cieniujące w XNA nie mają sensu na sprzęcie komputerowym, który nie ma takiej obsługi.
Im szybciej zdasz sobie sprawę, że .NET nie jest rozwiązaniem do izolowania programisty od podstawowych możliwości sprzętu i platformy natywnej, tym lepiej.
Na początku powiedziano, że niektóre interfejsy API i stosy są dostępne na wielu platformach, na przykład ASP.NET może być używany w systemach Windows, Linux, Solaris i MacOS X, ponieważ te interfejsy API istnieją zarówno w .NET, jak i Mono. ASP.NET nie jest dostępny na niektórych obsługiwanych platformach Microsoft, takich jak XBox lub Windows Phone 7 i nie jest obsługiwany na innych platformach obsługiwanych przez Mono, takich jak Wii lub iPhone.
Poniższe informacje są prawidłowe dopiero od 21 listopada i wiele rzeczy w świecie Mono prawdopodobnie się zmieni.
Te same zasady można zastosować do innych stosów, pełna lista wymagałaby odpowiedniej tabeli, której nie mam pojęcia, jak tu przedstawić, ale tutaj jest lista technologii, które mogą nie występować na konkretnej platformie. Możesz założyć, że wszystko, czego nie ma tutaj na liście, jest dostępne (możesz przesłać mi zmiany dotyczące rzeczy, które przegapiłem):
Core Runtime Engine [wszędzie]
Języki
Stosy serwerów
Stosy GUI
Biblioteki graficzne
Mono Libraries - Cross Platform, mogą być używane w .NET, ale wymagają ręcznego budowania
MonoTouch oznacza Mono działające na iPhonie; MonoDroid oznacza Mono działające na Androidzie; Porty PS3 i Wii są dostępne tylko dla programistów Sony i Nintendo.
Przepraszam za brak formalności.
źródło
Najpierw musisz wprowadzić rozróżnienie między infrastrukturą Common Language Infrastructure (otwarty standard) a .NET (implementacja tego standardu przez Microsoft). Mono to implementacja CLI i nigdy nie twierdziła, że jest „przenośnym .NET”. Ponadto język C # jest otwartym standardem i nie jest ściśle powiązany z .NET.
Nie wiem, czy Microsoft ma jakieś narzędzie do sprawdzania, czy implementacja jest zgodna, ale jeśli tak, to jestem pewien, że chłopaki mono to mają i używają.
Mono wlecze się za .Net, ale ledwo. Mono może uruchamiać kod C # 4.0 (aktualna wersja .NET). Ponadto Microsoft niedawno udostępnił cały kod DLR i biblioteki open source (na licencji Apache 2.0), co umożliwiło mono korzystanie z języków takich jak IronPython, IronRuby, a F # zostało otwarte jako źródło tylko w zeszłym tygodniu. Ponadto Microsoft regularnie publikuje CTP nadchodzących funkcji w .NET, co pozwala deweloperom mono na bieżąco z aktualnymi wersjami.
Istnieje wiele narzędzi i rozszerzeń w .NET, na przykład Kontrakty kodowe. Nie zawsze są one w pełni zaimplementowane w trybie mono. (Obecnie wydaje mi się, że istnieje częściowy weryfikator umów dla kontraktów Wymaga). Te i tak nie są powszechnie używane w aplikacjach .NET, ale jeśli ich popularność wzrośnie, zwiększy się także szybkość ich wdrażania w trybie mono.
WinFormy nie są (całkowicie) przenośne. Są one specyficzne dla platformy .NET i nie stanowią części interfejsu CLI. Interfejs CLI nie określa żadnego konkretnego zestawu widżetów. Istnieją jednak zestawy widżetów międzyplatformowych (GTK # i Silverlight). Jeśli pisałeś aplikację od podstaw z myślą o przenośności, użyłbyś jednego z nich zamiast Winforms / WPF. Ponadto mono zapewnia cienkie opakowanie dla interfejsu API Winforms - który umożliwia łatwiejsze przenoszenie istniejących aplikacji winforms do GTK # (bez całego przepisywania).
Mono zapewnia narzędzie, Mono Migration Analyzer (MoMA), które może pobrać istniejącą aplikację .Net i powiedzieć o jej przenośności. (np. zidentyfikuj używane nieobsługiwane biblioteki, P / Invokes itp.).
Dla firm, które nie chcą polegać na Open Source - licencje mono mogą być ponownie licencjonowane. Własność kodu dodanego do mono jest przekazywana nowemu, który może licencjonować go w alternatywny sposób inny niż zwykła licencja LGPL (która i tak ma bardzo niewiele ograniczeń).
Jeśli chodzi o stwierdzenie „.NET jest przenośny”, myślę, że może to być poprawne stwierdzenie, jeśli piszesz kod od podstaw i zdajesz sobie sprawę z problemów związanych z przenośnością frameworka. Jeśli twierdzenie jest takie, że „Mam aplikację Windows napisaną w .NET, powinna ona działać w trybie mono”, to nie jest to uzasadnione oświadczenie - ale Mono dołożyło starań, aby uprościć portowanie takich aplikacji.
źródło
the C# language is an open standard, and is not strictly tied to .NET.iC# 4.0 code (current .NET version)są ze sobą sprzecznePunkt po punkcie:
Istnieje specyfikacja zgodna z Microsoft CLR. Mono nie jest klonem CLR Microsoftu, ale raczej implementacją tej samej specyfikacji. Z jednej strony istnieje szansa, że spowoduje to jeszcze większą niezgodność. W praktyce działało to bardzo dobrze w przypadku mono.
Ponieważ dokumentacja .Net poprzedza faktyczną wersję, mono faktycznie zakończyło (nie wersję beta) obsługę .Net 4 przed oficjalną wersją Microsoft. Dodatkowo mono bardzo dobrze dokumentuje, które rzeczy nie są obsługiwane, i ma kilka narzędzi, które można uruchomić w stosunku do istniejącego projektu, aby pomóc Ci dostrzec miejsca z potencjalną niezgodnością.
Zdecydowana większość form winform działa dobrze. WPF, nie tak bardzo. Słyszałem, że to samo dotyczy Javy - wiele zaawansowanych zestawów narzędzi widget / gui nie jest tak dobrze obsługiwanych na wszystkich platformach.
Jeśli tak jest, to zdecydowanie nie będą korzystały z Javy, ponieważ to stawia platformę open source na jeszcze wyższym poziomie w planie A.
Podsumowując, jeśli chcesz zbudować aplikację wieloplatformowe teraz , nie ma nic złego w mono zaczynając od get-go i używając jej jako ram. Możesz nawet wdrożyć mono w systemie Windows, jeśli chcesz.
Z drugiej strony, jeśli chcesz dziś zbudować aplikację dla systemu Windows, która w przyszłości może być na różnych platformach, prawdopodobnie będziesz chciał skorzystać z natywnych widżetów i narzędzi systemu Windows. .Net wykonuje tutaj znacznie lepszą pracę niż Java, a mono jest całkowicie akceptowalnym wycofaniem w tym scenariuszu.
Innymi słowy: Tak, .Net, jeśli działa na różnych platformach w każdy sposób, który ma znaczenie dla twojego pytania. Nie, mono nie tylko uruchomi każdy program .Net od razu po wyjęciu z pudełka, ale twoje pytanie jest w kontekście nowego projektu. Nie wymaga wiele pracy, aby uniknąć problemów z nowymi projektami i uniknąć problemów ze zgodnością, szczególnie jeśli myślisz w kategoriach programowania dla mono, a nie dla .Net.
Przede wszystkim jednak uważam, że to niewłaściwe pytanie. O ile nie budujesz od podstaw nowego zespołu programistów, zaczynasz od programistów, którzy posiadają wiedzę specjalistyczną w tej czy innej dziedzinie. Twoje najlepsze wyniki zostaną osiągnięte dzięki temu, co wiedzą Twoi programiści. Wydaje się równie ważne, jak tworzenie aplikacji wieloplatformowej. Jeśli masz zespół pełen programistów .Net z niewielkim doświadczeniem w Javie, prawdopodobnie nie zwolnisz ich ani nie sprawisz, że wszyscy nauczą się języka Java na następny projekt. Jeśli masz zespół pełen programistów Java, nie poprosisz ich o naukę .Net dla projektu tylko dla systemu Windows. Każdy z nich byłby szalony.
źródło
Pracowałem z Mono i powiedziałbym, że jest tak dobry, jak to tylko możliwe, z alternatywną platformą, która jest open-source i nie jest bezpośrednio obsługiwana przez Microsoft. Jeśli możesz czuć się komfortowo, korzystając z alternatywnej platformy typu open source , takiej jak Clojure lub Scala, prawdopodobnie możesz czuć się swobodnie korzystając z Mono.
Poziom .NET obsługiwany przez Mono zawsze można znaleźć na stronie Mono Roadmap .
Czy wszystkie elementy GUI działają? O ile mi wiadomo, robią to, chociaż nie wyczerpałem wyczerpująco każdego elementu.
Czy Mono jest identyczne z .NET? Nie. Podejrzewam, że będą tu drobne (i może poważne) poprawki. Obecnie nie można na przykład uruchomić Entity Framework.
źródło
Jako cel wszechświat .NET / mono porusza się bardzo szybko .
Co kilka lat Microsoft wypuszcza kilka istotnych zmian i innowacji dotyczących języka, środowiska wykonawczego i infrastruktury otaczającej platformę .NET. Na przykład: Generics, LINQ, DLR, Entity Framework - z każdą nową wersją Visual Studio generalnie następuje znaczny wzrost zestawu funkcji i użyteczności frameworka, na który jest kierowany.
Chociaż ciągłe doskonalenie frameworka jest mile widziane, jest również problematyczne, jeśli chcesz kompatybilności na wielu platformach. Platformy obsługi długoterminowej, takie jak Red Hat Enterprise Linux, poruszają się glacjalnie powoli w zakresie wdrażania nowych technologii, aw dowolnym momencie nastąpi znaczna poprawa platformy Mono, która nastąpiła w ciągu ostatnich kilku miesięcy. Więc jeśli chcesz uruchomić rzeczy, które budują fajne dzieci, będziesz musiał skompilować Mono od zera i zarządzać własnymi łatkami i aktualizacjami. To nie fajne.
Z drugiej strony Java jest tak samo zastygła jak basen dla dzieci. Zwłaszcza teraz, gdy jest własnością firmy, która właśnie chciała Java w procesach patentowych, możesz być całkiem pewien, że w przewidywalnej przyszłości nie będzie żadnych wykrywalnych zmian w języku lub środowisku uruchomieniowym. Java jest tak stabilną platformą jak FORTRAN. To nie jest tak dobre, jeśli liczysz na jakiekolwiek ulepszenia, ale nie jest tak złe, jeśli próbujesz wdrożyć aplikację korporacyjną.
źródło
Z perspektywy użytkownika, Mono jest do bani w dostosowywaniu aplikacji Windows .NET do Linuksa. Jeśli faktycznie spróbujesz uruchomić jakąkolwiek przyzwoicie napisaną aplikację Windows w Mono, to nie zadziała.
Z punktu widzenia osoby pakującej (kiedyś pracowałem w PortableApps), .NET może być zarówno błogosławieństwem, jak i przekleństwem. Jeśli korzystasz tylko z systemu Windows, .NET znacznie ułatwia wdrażanie, ponieważ więcej bibliotek oznacza mniej rzeczy zależnych od systemu (w szczególności, sądzę, że między wersjami systemu Windows), ale jest również bardzo mylące, nawet w systemie Windows, ponieważ wersje .NET nie są wsteczne -kompatybilny lub zgodny do przodu. Musisz pobrać różne wersje .NET dla różnych programów.
To powiedziawszy, Mono jest dobrym punktem wyjścia do tworzenia programów C # między platformami. Tylko nie pakuj programu w najnowszą wersję WINE i nazwij to zrobionym. Zobacz, gdzie zabrał Picasę.
Podobnie jak w przypadku stabilności politycznej dwóch języków / platform, RMS prawdopodobnie zacząłby narzekać na to, jak na czele Mono stoi Novell, którego miesiąc miodowy z Microsoftem jest dość znany. Obie platformy można obecnie uznać za niestabilne politycznie.
Jeśli naprawdę chcesz mieć łatwą platformę, wypróbowaną i prawdziwą ścieżką jest QT, która jest obecnie dość stabilna politycznie, to: a) LGPL, b) zrobione z głównymi problemami licencyjnymi sprzed lat, oraz c) wspierane przez Nokię, która sprzedaje naprawdę bardzo popularne telefony.
źródło
Mono nie jest portem 1: 1 Microsoft .net. Istnieją technologie, których Mono po prostu nie wdroży lub nie ma takich planów (np. Workflow Foundation lub WPF ), podczas gdy z drugiej strony mają własne technologie, których Microsoft .NET nie robi, np. Rozszerzenia SIMD .
Krótka odpowiedź: Mono i Microsoft .NET są oparte na tych samych fundamentach - CIL i BCL - ale są osobnymi projektami.
źródło
Mały komentarz do wypowiedzi w oryginalnym poście. Będę argumentować, że TCK pozostaje teoretycznym narzędziem pozwalającym Oracle twierdzić, że Java jest otwartym standardem. Ponieważ, jeśli zauważysz, Apache Harmony od kilku lat bezskutecznie próbuje uzyskać certyfikat „Java”. Oczywiste jest, że Oracle tak naprawdę nie jest zainteresowany implementacją open source, oprócz tej, z którą są powiązani, i mniej lub bardziej kontroluje (OpenJDK), co przy okazji. podobnie jak Mono, nie jest kompletny (tj. nie obsługuje Java Web Start) i brakuje niektórych optymalizacji dostępnych w zamkniętej implementacji HotSpot.
Prawdopodobnie od 2010 r .; (większość) Java jest oprogramowaniem typu open source, ale nie jest otwartym standardem, podczas gdy (większość) .NET nie jest oprogramowaniem typu open source, ale otwartym standardem. Istnieją oczywiście wyjątki: DLR, IronPython, IronRuby i F # są w rzeczywistości oprogramowaniem typu open source. Mono jest interesujące, ponieważ zapewnia najlepsze z obu światów, otwarte implementacje otwartych standardów.
źródło
Odkładając na bok wszystkie szczegóły techniczne, bardzo ważna część ma miejsce podczas pisania kodu.
Podobnie jak w przypadku każdej technologii wieloplatformowej (czy to Java, Python, Ruby ...), jeśli kod nie jest napisany z myślą o przenośności, należy założyć, że nie ma praktycznie żadnej szansy, że kod będzie działał poprawnie (nawet jeśli taka szansa jest w rzeczywistości znacznie, dużo wyżej), ponieważ dziwne zachowanie może być dość krytyczne. Przeczytaj: nie bierz losowego zestawu i uruchom go pod Mono.
Jednak w przypadku nowego projektu (lub takiego, który można łatwo refaktoryzować) wybór .Net / Mono jako potencjalnie przenośnego środowiska wykonawczego ma sens, ale oszczędzasz sobie wielu kłopotów, testując swój kod na Mono bardzo wcześnie, nawet jeśli projekt ma tylko niewielka zmiana przechodzenia na wiele platform. Jeśli używasz serwera ciągłej integracji, może to być tak proste, jak skonfigurowanie węzła kompilacji Mono. Wiele problemów można rozwiązać podczas opracowywania, po prostu robiąc z tego nawyk (np. Budowanie ciągów ścieżek), a ogromna część kodu może być przenośna i testowana jednostkowo na Mono tylko przy użyciu rozsądnych praktyk i odrobiny uprzedzenia. Pozostała część (tj. Nieudane testy jednostkowe) jest wtedy specyficzna dla platformy (jak kod przy użyciu PInvoke), ale powinna być wystarczająco enkapsulowana, aby móc zapewnić alternatywną implementację dla platformy docelowej.
Oczywiście, użycie biblioteki Mono niedostępnej (.Net) lub kompatybilnej (strony trzeciej) w Mono wyklucza to, ale w mojej dziedzinie to jeszcze nie widać. To jest strategia, której faktycznie używamy w pracy, i stosując ją, nie boję się twierdzić, że .Net + Mono jest platformą wieloplatformową.
źródło
To zależy od uczciwej odpowiedzi. Widziałem małe serwery sieciowe przeniesione z IIS do Apache, działające pod mono bez prawie żadnych trudności. Z powodzeniem uruchomiłem niezmienione aplikacje Windows .Net przy użyciu Win Forms w systemie Linux.
Jednak chociaż może to działać, jeśli używasz wywołania API, które nie jest zaimplementowane w trybie mono, nie będzie działać, a jedynymi rozwiązaniami są albo przepisanie aplikacji, pozostanie przy systemie Windows lub napisanie dodatkowych rzeczy w mono.
źródło