ASP.NET MVC i Rails mają podobny obszar zastosowania, są zbudowane wokół tej samej architektury, oba frameworki są stosunkowo nowe i open source.
Jako programista Railsów chciałbym wiedzieć, co potrafi ASP.NET MVC, a Ruby on Rails nie, i odwrotnie?
ruby-on-rails
comparison
asp.net-mvc
Nikita Barsukov
źródło
źródło
Odpowiedzi:
Opracowałem prawdziwe aplikacje zarówno z Railsami, jak i ASP.NET MVC, ale ta odpowiedź zawiera istotne zastrzeżenie: nauczyłem się i rozwijałem z wcześniejszymi wersjami 2 Railsów, więc jest całkiem możliwe, że jestem bardzo nieaktualny z moim Wiedza o szynach.
Biorąc to pod uwagę, nie sądzę, że można coś zrobić z jednym, ale nie z drugim. Biorąc pod uwagę dowolny zestaw wymagań dla aplikacji internetowej, powinieneś być w stanie zbudować tę aplikację - prawdopodobnie równie wydajnie - za pomocą Railsów lub ASP.NET MVC.
Istnieje kilka ciekawych rzeczy, które - zgodnie z moją najlepszą wiedzą - są dostępne w ASP.NET MVC głównie ze względu na aspekty C # / .NET. Na przykład: gdy mam stronę zawierającą przesłany formularz, miałbym akcję, która sprawdza, czy zajmuje się GET lub POST, aby zdecydować, co zrobić:
Jest to trywialny przykład, ale
if request.post?
wzór jest niezwykle powszechny w Railsach. W przypadku nietrywialnych przypadków kod akcji może stać się duży i nieuporządkowany, a często chciałbym, aby móc go przeredagować na osobne metody. W ASP.NET MVC mogę to zrobić:Myślę, że możliwość czystego oddzielenia obsługi żądań GET i POST jest fajna. Twój przebieg może się różnić.
Inna rzecz, którą robi ASP.NET MVC, to jest super fajne (znowu moim zdaniem) jest również związane z obsługą formularzy POSTS. W Railsach muszę zapytać o
params
skrót dla wszystkich moich zmiennych formularza. Powiedzmy, że mam formularz z polami „status”, „gonkulated”, „invert” i „disposition”:Ale ASP.NET MVC pozwala mi uzyskać wszystkie wartości formularza jako parametry mojej metody Action:
To dwie rzeczy, które bardzo mi się podobały w ASP.NET MVC lub Railsach. Nie są wystarczającym powodem, dla którego rozsądny lub kompetentny programista wybiera jedną strukturę zamiast drugiej.
źródło
public ActionResult Edit(Foothing foothing)
tzn. Funkcje ModelBinder były jeszcze ładniejsze.Zaletą ASP.NET MVC w porównaniu z Railsami jest konieczność zbudowania nowej aplikacji w oparciu o istniejącą bazę danych. ActiveRecord w Railsach jest bardzo przekonany na temat struktury tabel (tabela musi mieć jedną i tylko jedną kolumnę całkowitą jako klucz podstawowy zwany „id” itp.), Więc jeśli istniejące tabele nie są zgodne z preferencjami ActiveRecord, trudno jest uczynić ActiveRecord praca. Ale tworzenie nowej aplikacji z nową db z ActiveRecord i Rails jest szybkie!
ASP.NET MVC nie ma domyślnej ORM. Możesz wybrać strategię dostępu do danych, która odpowiada Twoim potrzebom. Niektóre ORM, takie jak nhibernate, mogą obsługiwać starsze bazy danych. Możesz mieć klucz podstawowy GUID itp.
Istnieje alternatywa dla Rails ActiveRecord o nazwie DataMapper , ale nie próbowałem tego.
źródło
Po użyciu obu, IMO odpowiada, że ASP.NET MVC jest bardziej elastyczny niż Rails, jeśli twoja aplikacja potrzebuje więcej niż tylko odczytu / zapisu z bazy danych. Z mojego doświadczenia wynika, że Railsy szybko się psują, gdy tylko wprowadzisz do aplikacji jakąkolwiek złożoność lub logikę poza bardzo trywialną logiką CRUD. Program ASP.NET MVC nie napotyka tego ograniczenia, ponieważ jest bardziej „otwarty” na temat tego, co możesz zrobić.
Wszystkie pozostałe są równe w typowej aplikacji CRUD „Web 2.0”, nie można nic zrobić ponad drugą, ale w przypadku bardziej skomplikowanej aplikacji, która wymaga przepływu pracy lub różnych źródeł danych lub interakcji z inną aplikacją lub czymkolwiek że nie jest to typowy CRUD, ASP.NET można zrobić dużo więcej i nie są tak restrykcyjne, jak Rails.
źródło
Nigdy nie pracowałem z Ruby on Rails, więc nie mam odpowiednich kwalifikacji, aby odpowiedzieć na to pytanie, ale jedną rzeczą, którą bardzo lubię w ASP.NET MVC, jest bezpieczeństwo typu. To przeszkadza. Adam Crossland i rmac dotknęli go krótko w swoich komentarzach, ale chciałbym zauważyć, że przy użyciu metody kontrolera takiej jak poniżej, każdy z parametrów będzie mocno wpisany. To sprawia, że kod w metodzie Edit jest o wiele czystszy, ponieważ nie musisz się martwić konwertowaniem reprezentacji ciągów na zmienne o prawidłowym typie.
Innym miejscem, w którym pojawia się ten typ bezpieczeństwa, są Widoki i Widok częściowy, w którym można powiązać widok widoku częściowego z prostym, starym obiektem C #, który będzie służył jako model tego widoku lub widoku częściowego. Ułatwia to życie, szczególnie tam, gdzie chcesz zbudować hierarchię widoków zawierających inne widoki.
Jeśli
Infinity.ViewModels.Site
przestrzeń nazw zawiera klasę o nazwieContactViewModel
, to w przypadku widoków Razor robisz to, umieszczając taką linię w górnej części widoku:a dla widoków ASPX robisz to, deklarując widok w ten sposób:
Kojarzysz rzeczywistą instancję obiektu modelu z widokiem w metodzie akcji Kontroler, a następnie uzyskujesz dostęp do instancji obiektu modelu w widoku za pomocą
Model
właściwości widoku.Ta mocna maszyna jest dla mnie super fajna. Zespół, który stworzył ASP.NET MVC, włożył wiele wysiłku, aby każdy z 3 obszarów Modelu, Widoku i Kontrolera był mocno wpisany.
Nie jestem pewien, czy Ruby-on-Rails ma to, ale mam taką nadzieję.
źródło
Są bardzo podobne i wszyscy mogą „robić to samo” głównie, tylko niektóre rzeczy są łatwiejsze w jednym i trudniejsze niż inne.
Użyłem ASP.NET MVC wokół oryginalnej wersji i zdecydowanie był to klon Railsów minus activerecord. Tak więc Railsy prawie na pewno mają znacznie większy zestaw funkcji i znacznie większy ekosystem wtyczek / klejnotów.
źródło
Według mojego ograniczonego doświadczenia główną zaletą ASP.NET MVC jest to, że jest to język skompilowany. Pozwala to wykryć niektóre błędy programistyczne już podczas kompilacji, w których Ruby musi polegać na wykrywaniu podczas testów jednostkowych.
Również fakt, że jest on kompilowany, pozwala mieć zaawansowane narzędzia do refaktoryzacji, np. Zmienić nazwę właściwości w jednym miejscu, a wszystkie odwołania do właściwości są zmieniane. Tego przynajmniej nie można zrobić w TextMate, którego używa wielu programistów Railsów.
Z drugiej strony, główną zaletą Ruby on Rails jest to, że jest to język interpretowany;) Natura Ruby, jak możesz modyfikować dowolny obiekt w pamięci lub małpować łatę klasy, może prowadzić do bardzo eleganckich rozwiązań; sprawdź przykłady Elokwentnego Rubinowego . Duża część samego środowiska Rails opiera się na tej zdolności.
Możliwość zastąpienia dowolnej metody w dowolnym obiekcie w dowolnym momencie bardzo mi pomogła w pisaniu testów jednostkowych. W .NET kontenery wstrzykiwania zależności i IOC są praktycznie wymaganiami do tworzenia testowalnego kodu. W Ruby nie jest to konieczne.
Edytować:
Po przemyśleniu, prawdopodobnie zabójczą funkcją Railsów jest migracja bazy danych. Środowisko ASP.NET MVC samo w sobie nie zapewnia żadnej obsługi bazy danych. .NET Framework ma pewne komponenty dostępu do danych / ORM, np. Entity Framework i Linq do Sql. Ale nie ma żadnych narzędzi do projektowania struktury bazy danych.
Jeśli zapłacisz za jedną z droższych wersji VS, możesz uzyskać Data Dude , która pozwala zaprojektować schemat bazy danych i mieć narzędzia do wdrażania schematu w bazie danych. Ale o ile wiem, obsługa migracji z wcześniejszych wersji aplikacji jest bardzo ograniczona.
Niektórzy twierdzą, że ASP.NET MVC nie jest tak naprawdę frameworkiem MVC, a jedynie frameworkiem VC, z powodu braku obsługi migracji bazy danych.
Edytuj (ponownie):
Zmiany w Visual Studio toolchain / EF wprowadziły migracje oparte na kodzie od mojej ostatniej edycji. (ale sprawdź także FluentMigrator, jeśli idziesz tą ścieżką)
źródło
Moim głównym problemem związanym z Microsoft MVC 3 i Entity Framework są ich zadziwiająco złe zasady projektowania.
Jednym z pierwszych problemów, na jakie natrafiłem, było użycie innej klasy jako właściwości i próba stworzenia listy rozwijanej dla możliwych wartości.
Aby zilustrować moją tezę, powiedz, że masz dwie takie klasy modeli:
Utworzenie właściwości Kolor wystarczyłoby dla prawdziwej ORM, ale nie dla EF. Musisz dodać nadmiarowy identyfikator właściwości Color w klasie Thing w następujący sposób:
Jeśli nie dodasz nadmiarowego pola identyfikatora dla odniesienia do obiektu obcego, nie możesz łatwo utworzyć list rozwijanych ze wszystkimi możliwymi opcjami z połączonej klasy.
To naprawdę okropny projekt, ponieważ silnie łączy wewnętrzne funkcjonowanie jednej klasy z drugą. Rzecz nie powinna wiedzieć nic o ColorID, klasa Color powinna obsługiwać własne kontrole równości bez ujawniania, że ma nawet identyfikator.
To są najlepsze praktyki 101 rzeczy, ale najwyraźniej Microsoft nie zdaje sobie sprawy z podstawowych zasad informatyki i programowania obiektowego. [/ Rant]
źródło
int?