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

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?

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.

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.

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.

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ę.

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.

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

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]