Co może zrobić ASP.NET MVC, a Ruby on Rails nie? [Zamknięte]

37

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?

Nikita Barsukov
źródło
Świetne pytanie. Jestem programistą MVC i chętnie znam odpowiedź na to pytanie.
StuperUser
14
Tego rodzaju pytania są otwarte i lepiej na nie odpowiedzieć trollując IMHO w Internecie. Co może zrobić BMW 335, czego nie potrafi Hyundai Sonata? Oba mają 4 próby, kierownicę i są zbudowane na tej samej strukturze zużycia; paliwo. Te pytania pojawiają się z powodu braku badań nad zrozumieniem podanych tematów, co może ułatwić bardziej bezpośrednie pytanie ... Jestem pewien, że wielu się nie zgodzi, ponieważ są to programiści ...
Aaron McIver
1
@Aaron - Chociaż miałem problem z dodaniem odpowiedzi na to pytanie, zasadniczo zgadzam się z tobą i mam nadzieję, że wyjaśniłem, że aby pożyczyć twój analog, porównujemy jeden samochód z drugim.
Adam Crossland
10
Osobiście uważałem, że to ważne pytanie. Takie pytania nie powinny być tak łatwo zastrzelone, ponieważ wielu z nas zna tylko jedną stronę historii, a to pomaga zrozumieć także drugą stronę. BTW, zadawanie pytań na StackExchange kwalifikuje się jako badanie w mojej książce.
Umar Farooq Khawaja,
3
Często zadaję takie pytania i każę im zestrzelić, dlatego chciałbym tu okazać wsparcie dla PO. Decyzje podejmowane podczas kodowania są prawie zawsze subiektywne. Moje prawo może być twoim błędem, podczas gdy oba mogą opracować działające rozwiązania o równej (subiektywnej) wartości. W tym przypadku PO chce opinii na temat względnych zalet dwóch przeciwstawnych technologii. Nigdzie nie znajdziesz tych informacji poza umysłami tych, którzy przeszli przez praktyczny proces wybierania jednej z nich. Jest to zatem uzasadnione pytanie.
Ian

Odpowiedzi:

31

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ć:

def edit
  @item = Item.find(params[:id])

  if request.post? 
    @item.update_attributes(params[:item])
    redirect_to :action => 'edit', :id => @item.id 
  end
end

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ć:

public ActionResult Edit() {
  // Render my page that has the Edit form
  ...
}

[HttpPost]
public ActionResult Edit(Foothing foo) {
  // Save my Foothing data
  ...
}

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 paramsskrót dla wszystkich moich zmiennych formularza. Powiedzmy, że mam formularz z polami „status”, „gonkulated”, „invert” i „disposition”:

def edit
  @item = Item.find(params[:id])

  if params[:status] == "new"
    ...
  else
    ...
  end

  if params[:gonkulated] == "true"
    ...
  else
    ...
  end

  if params[:invert] == "true"
    ...
  else
    ...
  end

  # Rest ommited for brevity
end

Ale ASP.NET MVC pozwala mi uzyskać wszystkie wartości formularza jako parametry mojej metody Action:

[HttpPost]
public ActionResult Edit(int id, string status, bool gonkulated, bool invert, int disposition) {
    ...
}

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.

Adam Crossland
źródło
6
Jeśli chodzi o parametry akcji: pomyślałbym, że public ActionResult Edit(Foothing foothing)tzn. Funkcje ModelBinder były jeszcze ładniejsze.
rmac
10
Przykłady szyn są dość nieaktualne. Działają, ale są na to lepsze sposoby.
Jason w
2
@Jason: czy zależy Ci na tym, aby rozwinąć i być może umieścić sens ?
Dan
3
Zgadzam się, że request.post? też wydaje mi się niezwykły (może dlatego, że był używany w starszych wersjach). Zacząłem od Rails 3, a metodą edycji jest zawsze „get”. Przypuszczam, że możesz skonfigurować go jako post, ale Railsy używają wzorca RESTful, który użyłby metody „update” do wykonania postu dla wszelkich zmian, które wystąpiłyby w modelu. Więc jeśli zrobisz to poprawnie, nie powinieneś nawet sprawdzać, czy metoda „edit” była postem.
PhillipKregg
3
Głosowanie po prostu dlatego, że przedstawiacie rozsądny argument. Wolę Railsy, ​​ale jest to całkowicie subiektywne i dobrze argumentujesz.
Steve Hill
6

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.

Endy Tjahjono
źródło
9
ActiveRecord Ruby pozwala na wyeliminowanie dużej ilości kodu, jeśli przestrzegasz pewnych konwencji, ale nie jest to wymagane. Jeśli konwencje nie są przestrzegane, musisz być bardziej jednoznaczny.
kevin cline
1
ASP.NET MVC ma Entity Framework dla ORM, który do tej pory był całkiem niesamowity z mojego doświadczenia.
Cooper
Jeśli przez awesome masz na myśli wykonywanie źle wygenerowanych zapytań 20 razy wolniej niż poprawnie napisany SQL, to tak;) ... Dapper Contrib to coś, co znalazłem świetne i szybkie ...
niico
2

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.

Wayne Molina
źródło
9
-1 Nie widzę żadnego powodu, dla którego ASP.NET MVC byłby uważany za bardziej elastyczny - jeśli spojrzysz na główne komponenty, routing, kontrolery, rendering, wszystkie one są po prostu zrywane z szyn i brakuje im również wielu funkcji.
scottschulthess
1
W jaki sposób asp.net mvc jest „bardziej otwarty”? Mogę pominąć całe rusztowanie, a moje modele i sterowniki od zera, a także tworzyć zagnieżdżone skojarzenia - od jednego do wielu, od wielu do jednego, od wielu do wielu - bez żadnego „załamania się”. A jeśli zdecyduję się na użycie interfejsu JavaScript typu javascript, równie łatwo mogę wysłać wszystkie moje dane modelu do klienta w formacie JSON (lub XML lub innym formacie). Dodatkowo, jeśli możesz pomyśleć o funkcjonalności, którą chciałbyś wdrożyć, prawdopodobnie jest to już klejnot. Nie jest trudno znaleźć nietrywialne aplikacje Railsowe.
PhillipKregg
2
Możliwość przejścia do surowego frameworka c # / .net można uznać za bardziej elastyczny?
Chris Barry
2
Bardzo późno, ale to, co miałem na myśli w tym poście, to ASP.NET MVC pozwala na upuszczenie do C # / .NET i wykorzystanie całego frameworka. Szyny w tym czasie (około 2.0, myślę, że nie pamiętam) w zasadzie sprawiły, że CRUD był bardzo łatwy, a wszystko inne trudne; projekt, nad którym pracowałem, kiedy to napisałem, został wykonany w Railsach (mój błąd) i zepsuł się w momencie, gdy robiliśmy logikę wykraczającą poza „odczyt z bazy danych, wyświetlanie na stronie”, gdybym to zrobił w C # / ASP.NET MVC ( 1.0 w tym momencie IIRC) Nie napotkałbym wielu problemów, które zrobiłem, wybierając zamiast tego Railsy dla aplikacji.
Wayne Molina,
2

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.

[HttpPost]
public ActionResult Edit(int id, string status, bool gonkulated, bool invert, int disposition) {
    ...
}

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.Siteprzestrzeń nazw zawiera klasę o nazwie ContactViewModel, to w przypadku widoków Razor robisz to, umieszczając taką linię w górnej części widoku:

@model Infinity.ViewModels.Site.ContactViewModel

a dla widoków ASPX robisz to, deklarując widok w ten sposób:

<%@ Page Language="C#" ="~/Views/Shared/Site.master" ="System.Web.Mvc.ViewPage<Infinity.ViewModels.Site.ContactViewModel>" %>

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ą Modelwł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ę.

Umar Farooq Khawaja
źródło
Język Ruby jest również silnie pisany (także pisany kaczką). Railsy używają aktywnego rekordu do automatycznego kojarzenia swoich modeli z widokami. Nie musisz ich deklarować w kontrolerze. Aby utworzyć zagnieżdżoną hierarchię widoków, należy utworzyć w kontrolerze zmienną instancji reprezentującą modele, które mają zostać przekazane do widoku. Tak, oboje mogą zrobić to samo.
PhillipKregg
1

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.

scottschulthess
źródło
2
To prawda - ale Rails istnieje już od około 8 lat, więc ma przewagę. Przychodzę z Rails do asp.net, a MVC 3 jest naprawdę bardzo fajny. Jak dotąd Entity Framework i menedżer pakietów NuGet były dla mnie imponujące.
PhillipKregg
1

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ą)

Pete
źródło
2
Entity Framework 5.0 Code First obsługuje migracje
hofnarwillie
W rzeczywistości pierwsze migracje kodu są obsługiwane od wersji 4.1, która została wydana przez AFAIK niedługo po mojej edycji.
Pete,
-1

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:

public class Color
{
    public int ID { get; set; }
    public string Name { get; set; }
}

public class Thing
{
    public int ID { get; set; }
    public string Name { get; set; }
    public virtual Color Color { get; set; }
}

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:

public class Thing
{
    public int ID { get; set; }
    public string Name { get; set; }
    public int ColorID { get; set; }
    public virtual Color Color { get; set; }
}

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]

Mike Bethany
źródło
8
Nie potrzebujesz właściwości klucza obcego w obiektach struktury encji. Ponadto EF jest całkowicie oddzielnym produktem i nie jest w żaden sposób zintegrowany z ASP.NET MVC. Powinieneś używać modeli widoków do konstruowania interfejsu użytkownika i tworzenia list rozwijanych lub innych formantów.
Lucyfer Sam
Zgadzam się. Nie powinieneś mieć żadnych kluczy identyfikacyjnych w swoich strukturach encji. ORM powinien obsługiwać tożsamość obiektu. Ale punkt wzięty; Naprawdę narzekam bardziej na okropną EF ORM. Ten przykład jest uproszczoną wersją pochodzącą bezpośrednio od Microsoft. Tak właśnie robią w przykładzie ContosoUniversity. To przemawia do mnie. Microsoft nie wie, jak zrobić MVC lub ORM i pokazują to ich przykłady.
Mike Bethany
1
Dodanie właściwości ColorID pozwala wdrożyć leniwe wzorce ładowania, co czasami jest bardzo przydatne. Na przykład, jeśli obiekt, do którego istnieje odwołanie, jest bardzo duży i naprawdę nie potrzebujesz wszystkich wartości właściwości obiektu, wówczas marnowanie czasu na jego pobranie byłoby tylko znalezieniem powiązanej z nim części identyfikatora (ColorID) . Pozwala także na implementację kluczy obcych Nullable / Nonululowalnych, tzn. Co jeśli kolor nie zawsze jest potrzebny? Zmień ColorID na Nullable Integerint?
hofnarwillie