it-swarm-eu.dev

Co ASP.NET MVC umí a Ruby on Rails nemůže?

ASP.NET MVC a Rails) mají podobnou oblast použití, jsou postaveny na stejné architektuře, oba rámce jsou relativně nové a otevřené zdroje.

Jako programátor Rails) bych rád věděl, co dokáže ASP.NET MVC a Ruby on Rails nemůže, a naopak?

37
Nikita Barsukov

Vyvinul jsem skutečné aplikace s oběma Rails a ASP.NET MVC), ale tato odpověď přichází se značnou výzvou: Naučil jsem se a vyvíjel se s předběžnou verzí 2 Rails, takže je zcela možné, že jsem Jsem nesmírně zastaralý díky mým znalostem Rails).

Jak už bylo řečeno, nemyslím si, že existuje cokoli , které lze s jedním, ale ne s druhým. Vzhledem k jakémukoli souboru požadavků na webovou aplikaci byste měli být schopni sestavit tuto aplikaci - pravděpodobně stejně efektivně - pomocí Rails nebo ASP.NET MVC).

Existuje několik úhledných věcí, které - podle mého nejlepšího vědomí - jsou k dispozici v ASP.NET MVC hlavně kvůli aspektům C # /. NET. Například: když mám stránku, která obsahuje odeslaný formulář, mám akci, která zkontroluje, zda se jedná o GET, nebo POST), abych rozhodla, co dělat:

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

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

Toto je triviální příklad, ale if request.post? vzor je v Rails velmi běžný. V netriviálních případech může být kód akce velký a chaotický a často bych si přál, abych ho mohl čistě promítnout do samostatných metod. V ASP.NET MVC to mohu udělat:

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

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

Myslím, že schopnost čistě oddělit vyřizování žádostí GET a POST žádostí) je elegantní. Váš počet najetých kilometrů se může lišit.

Další věc, kterou ASP.NET MVC dělá, že je super v pohodě (opět podle mého názoru), souvisí také s manipulací s POSTS. V Rails musím dotazovat params hash pro všechny mé proměnné formuláře. Řekněme, že mám formulář s poli „status“, „gonkulated“, „invert“ a „dispozice“:

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 úhledně mi umožňuje získat všechny hodnoty formuláře jako parametry mé metody Akce:

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

To jsou dvě věci, které se mi na ASP.NET MVC nebo Rails opravdu líbily. Nestačí, aby si nějaký rozumný nebo kompetentní vývojář vybral jeden rámec nad druhým.

31
Adam Crossland

Jednou z výhod ASP.NET MVC oproti Rails) je, pokud potřebujete sestavit novou aplikaci přes existující databázi. Rails 'ActiveRecord je velmi o tom, jak by měly být tabulky strukturovány (tabulka musí mít jednu a pouze jeden celočíselný sloupec jako primární klíč s názvem 'id' atd.), takže pokud vaše stávající tabulky neodpovídají preferencím ActiveRecordu, je těžké zajistit, aby ActiveRecord fungoval. Ale vyvíjení nové aplikace s novou db s ActiveRecord a Rails je rychlý!

ASP.NET MVC nemá výchozí ORM. Můžete si vybrat strategii přístupu k datům, která odpovídá vašim potřebám. Některé ORM jako nhibernate mohou podporovat starší databáze. Můžete mít hlavní primární klíč atd.

Existuje alternativa k Rails ActiveRecord s názvem DataMapper ), ale nezkoušel jsem to.

6
Endy Tjahjono

Nikdy jsem nepracoval s Ruby) na Rails, takže nejsem přesně kvalifikovaný, abych odpověděl na tuto otázku, ale jedna věc, která se mi na ASP.NET MVC nesmírně líbí, je typová bezpečnost. Adam Adam Crossland a rmac se jej krátce dotkli ve svých komentářích, ale rád bych zdůraznil, že s metodou kontroleru, jako je následující, bude každý parametr silně zadán. Díky tomu je kód v rámci metody Edit mnohem čistší v že se nemusíte obávat převodu řetězcových reprezentací na správně zadané proměnné.

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

Druhé místo, kde se tato typová bezpečnost zobrazuje, je v pohledech a částečném pohledu, kde je možné spojit pohled částečného pohledu s obyčejným starým objektem C #, který bude sloužit jako model tohoto pohledu nebo částečného pohledu. Díky tomu je život mnohem snazší, zejména tam, kde chcete vytvořit hierarchii pohledů, které obsahují další pohledy.

Pokud Infinity.ViewModels.Site je obor názvů, který obsahuje třídu nazvanou ContactViewModel, pak pro zobrazení Razor to uděláte tak, že na začátek pohledu umístíte řádek takto:

@model Infinity.ViewModels.Site.ContactViewModel

a pro zobrazení ASPX to provedete deklarováním pohledu takto:

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

Přiřadíte skutečnou instanci objektu modelu k pohledu v metodě akce Controller a poté přistoupíte k instanci objektu modelu v pohledu pomocí vlastnosti Model pohledu.

Tato silně typovaná ness je pro mě skvělá. Tým, který vytvořil ASP.NET MVC, vynaložil velké úsilí, aby silně zadal každou ze 3 oblastí Modelu, Pohledu a Řadiče.

Nejsem si jistý, jestli to Ruby-on-Rails má, ale doufám.

2

Po použití obou je odpověď IMO taková, že ASP.NET MVC je flexibilnější než Rails, pokud vaše aplikace potřebuje více než jen čtení/zápis z databáze. Podle mých zkušeností Rails) se rozpadá rychle a těžce v okamžiku, kdy do aplikace zavedete jakýkoli druh složitosti nebo logiky nad velmi triviální logiku CRUD. ASP.NET MVC se s tímto omezením nesetkává, protože je to více "otevřený" o tom, co můžete udělat.

Všechny ostatní jsou stejné v typické aplikaci CRUD „Web 2.0“, že neexistuje nic, co by člověk mohl udělat za druhým, ale pro komplikovanější aplikaci, která potřebuje pracovní postup nebo různé zdroje dat, nebo pro interakci s jinou aplikací, nebo čímkoli že není typický CRUD, ASP.NET umí mnohem více a ne tak omezující jako Rails.

2
Wayne Molina

Jsou si velmi podobné a všichni dokážou „dělat totéž“ většinou, jen některé věci jsou jednodušší a těžší než jiné.

Použil jsem ASP.NET MVC kolem původního vydání a rozhodně to bylo Rails klon minus activerecord.) Rails má téměř jistě mnohem větší sadu funkcí a mnohem větší ekosystém plugin/gem.

1
scottschulthess

Podle mých omezených zkušeností je hlavní výhodou ASP.NET MVC to, že se jedná o kompilovaný jazyk. To vám umožní detekovat některé programovací chyby již při kompilaci, kde Ruby se musí spoléhat na detekci pak během testování jednotky).

Také skutečnost, že je sestavena, umožňuje mít pokročilé nástroje refaktoringu, např. změňte název vlastnosti na jednom místě a změní se všechny odkazy na vlastnost. To alespoň nelze provést v programu TextMate, který používá mnoho vývojářů Rails).

Na druhou stranu hlavní výhodou Ruby on Rails) je, že se jedná o interpretovaný jazyk;) Povaha Ruby, jak můžete upravit jakýkoli objekt v paměti, nebo opice patch třídy, může vést k některým velmi elegantním řešením, podívejte se na knihu Eloquent Ruby pro některé příklady. A hodně z Rails Rámec sám je založen na této schopnosti.

Schopnost nahradit jakoukoli metodu u jakéhokoli objektu kdykoli mi také velmi pomohla při psaní jednotkových testů. V .NET jsou Dependency Injection a IOC kontejnery) prakticky požadavky na vytvoření testovatelného kódu. V Ruby to není nutné.

Upravit:

Poté, co o tom přemýšlíte, pravděpodobně zabijáckou funkcí Rails je migrace databáze.) Rámec ASP.NET MVC sám o sobě neposkytuje žádnou podporu databáze. Rámec .NET má některé komponenty pro přístup k datům/ORM, např. Entity Framework a Linq to Sql, ale nemá žádné nástroje pro navrhování struktury databáze.

Pokud platíte za jednu z dražších verzí VS, můžete získat Data Dude , které vám umožní navrhnout schéma databáze a mít nějaké nástroje pro nasazení schématu do databáze. Ale pokud vím, podpora zpracování migrací z dřívějších verzí aplikace je velmi omezená.

Někteří tvrdí, že ASP.NET MVC není ve skutečnosti rámcem MVC, pouze rámcem VC), kvůli nedostatečné podpoře migrace databáze.

Upravit (znovu):

Změny v nástroji Visual Studio/EF zavedly migrace založené na kódu od mé poslední úpravy. (ale také se podívejte na FluentMigrator, pokud jdete touto cestou)

1
Pete