Ne ASP.NET MVC yapabilir ve Ruby on Rails yapamaz? [kapalı]

ASP.NET MVC ve Rails benzer kullanım alanlarına sahiptir, aynı mimari yapı etrafında inşa edilmiştir, her iki çerçeve de nispeten yeni ve açık kaynaktır.

Yani bir Rails programcısı olarak bilmek istiyorum, ASP.NET MVC ne yapabilir ve Ruby on Rails ne yapabilir ve tam tersi?

Hem Rails hem de ASP.NET MVC ile gerçek uygulamalar geliştirdim, ancak bu cevap önemli bir uyarı ile geldi: Ön sürüm 2 Rails ile öğrendim ve geliştirdim, bu nedenle tamamen eski durumdayım. Bilgi Rails.

Olduğu söyleniyor, biriyle yapılabilecek hiçbir şey olduğunu sanmıyorum . Bir web uygulaması için herhangi bir gereksinim kümesi göz önüne alındığında, bu uygulamayı Rails veya ASP.NET MVC ile muhtemelen eşit derecede verimli bir şekilde oluşturabilmelisiniz.

Bildiğim kadarıyla, ASP.NET MVC’de, çoğunlukla C # /. NET’in özelliklerinden dolayı mevcut olan birkaç güzel şey var. Örneğin: gönderilen bir form içeren bir sayfam olduğunda, ne yapılacağına karar vermek için bir GET veya POST ile ilgilenip ilgilenmediğini kontrol eden bir Eylemim olacaktır:

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

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

Bu önemsiz bir örnektir, ancak if request.post?desen Rails'de oldukça yaygındır. Önemsiz olmayan durumlar için, Eylem kodu büyük ve karışık olabilir ve sık sık, temiz bir şekilde ayrı yöntemlerle yeniden düzenlemeyi isterdim. ASP.NET MVC’de bunu yapabilirim:

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

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

GET ve POST isteklerinin işlenmesini temiz bir şekilde ayırabilmenin temiz olduğunu düşünüyorum. Kilometreniz değişebilir.

ASP.NET MVC’nin bunu çok iyi yaptığını söyleyen diğer şey (bence yine de) POSTS formunu kullanmakla da ilgili. Rails'de, paramstüm form değişkenlerimin karmasını sorgulamalıyım . Diyelim ki 'statü', 'gonkulated', 'invert' ve 'disosition' alanlarıyla bir formum var:

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

Ancak ASP.NET MVC düzgünce tüm form değerlerimi Action yöntemime parametre olarak almamı sağlıyor:

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

Bunlar ASP.NET MVC veya Rails hakkında gerçekten sevdiğim iki şey. Herhangi bir aklı başında veya uzman geliştiricinin bir çerçeveyi diğerine seçmesi için bir neden yeterli değildir.

ASP.NET MVC'nin Rails üzerinden bir avantajı, mevcut bir veritabanı üzerinden yeni bir uygulama oluşturmanız gerekmesidir. Rails'in ActiveRecord'u tabloların nasıl yapılandırılması gerektiği hakkında çok düşünülür (tablonun 'id', vb. Adında birincil anahtar olarak bir ve sadece bir tamsayı sütunu olması gerekir). iş. Ancak ActiveRecord ve Rails ile yeni db ile yeni uygulama geliştirmek hızlı!

ASP.NET MVC varsayılan ORM'ye sahip değildir. İhtiyacınıza uygun bir veri erişim stratejisi seçebilirsiniz. Bazı ORM nhibernate benzeri, eski veritabanlarını destekleyebilir. Rehberde birincil anahtar vb. Olabilir.

DataMapper adında Rails ActiveRecord'un bir alternatifi var, ancak denemedim.

Her iki kullanmış, cevap IMO uygulamanızın ihtiyaç birden yapmak durumunda ASP.NET MVC Raylar daha esnek olmasıdır sadece bir veritabanından okuma / yazma. Tecrübelerime göre Rails, çok önemsiz CRUD mantığının ötesinde uygulamaya her türlü karmaşıklığı veya mantığı uyguladığınız anda hızla ve ağır bir şekilde bozuluyor. ASP.NET MVC, yapabilecekleriniz hakkında daha "açık" olduğundan bu kısıtlama ile karşılaşmaz.

Tipik bir "Web 2.0" CRUD uygulamasında herkesin eşit olması, birinin diğerine yapabileceği bir şey değil, iş akışı gerektiren veya veri kaynaklarını farklılaştıran veya başka bir uygulamayla veya başka bir şeyle etkileşime giren daha karmaşık bir uygulama için bu tipik bir CRUD değildir , ASP.NET daha fazlasını yapabilir ve Rails kadar kısıtlayıcı olamaz.

Ruby on Rails ile hiç çalışmamıştım, bu yüzden bu soruyu cevaplamaya tam olarak yetkin değilim, ancak ASP.NET MVC'de sevdiğim tek şey tür güvenliği. Bu şekilde gelir. Adam Crossland ve rmac yorumlarında kısaca değindiler, ancak aşağıdaki gibi bir denetleyici yöntemle parametrenin her birinin güçlü bir şekilde yazılacağını belirtmek isterim. Bu, Düzenleme yöntemi içindeki kodu, dize gösterimlerini doğru şekilde yazılan değişkenlere dönüştürmekten endişe duymanıza gerek kalmaması için çok daha temiz hale getirir.

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

Bu tür güvenliğin ortaya çıktığı diğer bir yer, bir Kısmi Görünüm görünümünü, Kısmi Görünüm görünümünü, o Görünümün veya Kısmi Görünümün modeli olarak kullanılabilecek bir Eski Eski C # nesnesiyle ilişkilendirebileceği Görünümler ve Kısmi Görünümdedir. Bu, özellikle başka görüşler içeren bir görünüm hiyerarşisi oluşturmak istediğinizde hayatı çok kolaylaştırır.

Eğer Infinity.ViewModels.Siteadı verilen bir sınıfı içeren ad alanı ise, ContactViewModelRazor görünümleri için, görünümün üstüne böyle bir satır koyarak bunu yapın:

@model Infinity.ViewModels.Site.ContactViewModel

ASPX görünümleri için görünümü şu şekilde bildirerek yaparsınız:

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

Model nesnesinin gerçek örneğini Denetleyici eylem yöntemindeki görünümle ilişkilendirir ve ardından görünümdeki model nesnesinin örneğine görünümün Modelözelliğine erişirsiniz .

Bu güçlü yazı, benim için süper havalı. ASP.NET MVC'yi oluşturan ekip, her 3 Model, Görüntüleme ve Denetleyici alanını güçlü bir şekilde yazmak için çok çaba harcadı.

Ruby-on-Rails'in buna sahip olup olmadığından emin değilim, ama umarım öyledir.

Çok benzerler ve hepsi "aynı şeyi yapabilir" çoğunlukla, sadece bir kısmı birinden daha kolay ve diğerinden daha zor.

Orijinal sürüm çevresinde ASP.NET MVC kullandım ve kesinlikle bir Rails klonu eksi etkindi. Yani, Rails neredeyse kesinlikle çok daha büyük bir özellik ve daha büyük bir eklenti / gem ekosisteme sahiptir.

Sınırlı deneyimime göre, ASP.NET MVC'nin ana avantajı, derlenmiş bir dil olmasıdır. Bu, bazı programlama hatalarını derlemede algılamanıza izin verir; bu durumda Ruby, ünite testi sırasında tespit etmeye dayanır.

Ayrıca, derlenmiş olması, yeniden düzenleme araçlarının gelişmiş olmasını mümkün kılar, örneğin bir mülkün adını tek bir yerde değiştirme ve mülkün tüm referansları değiştirilir. Bu en azından birçok Rails geliştiricisinin kullandığı TextMate'te yapılamaz.

Öte yandan, Ruby on Rails'in temel avantajı, yorumlanmış bir dil olmasıdır;) Ruby'nin doğası, bellekteki herhangi bir nesneyi nasıl değiştirebileceğinizi veya bir sınıf maymunu yaması, çok zarif çözümlere yol açabilir; Bazı örnekler için Eloquent Ruby kitabını inceleyin . Ve Rails çerçevesinin büyük bir kısmı bu yeteneğe dayanmaktadır.

Herhangi bir yöntemde herhangi bir nesneyi herhangi bir zamanda değiştirme yeteneği de ünite testleri yazarken bana çok yardımcı oldu. .NET'te, Bağımlılık Enjeksiyonu ve IOC kapları test edilebilir kod oluşturmak için neredeyse zorunludur. Ruby'de buna gerek yok.

Düzenle:

Bunu düşündükten sonra, muhtemelen Rails'in katil özelliği veritabanı göçüdür. ASP.NET MVC çerçevesi kendi başına herhangi bir veritabanı desteği sağlamaz. .NET framework bazı veri erişim bileşenlerine / ORM'ye sahiptir, örneğin Entity Framework ve Sql'ye Linq. Ancak veritabanı yapısını tasarlamak için herhangi bir aracı yoktur.

VS'nin daha pahalı sürümlerinden biri için ödeme yaparsanız, bir veritabanı şeması tasarlamanıza ve şemayı bir veritabanına dağıtmak için bazı araçlara sahip olmanıza olanak sağlayan Data Dude'ı alabilirsiniz . Ancak söyleyebileceğim kadarıyla, uygulamanın önceki sürümlerinden gelen göçlerle ilgili destek çok sınırlı.

Bazıları ASP.NET MVC'nin veritabanı geçişi için destek yetersizliğinden dolayı gerçekten bir MVC çerçevesi olmadığını, sadece VC çerçevesini oluşturduğunu iddia ediyor.

Düzenle (tekrar):

Visual Studio toolchain / EF’de yapılan değişiklikler, son düzenlememden bu yana kod tabanlı taşımayı başlattı. (ama aynı zamanda bu yolda ilerliyorsanız FluentMigrator'ı da kontrol edin)

Microsoft'un MVC 3 ve Entity Framework'le ilgili en büyük sorunum şaşırtıcı derecede kötü tasarım ilkeleri.

Karşılaştığım ilk sorunlardan biri, başka bir sınıfı mülk olarak kullanmak ve olası değerler için bir açılır liste oluşturmaya çalışmaktı.

Benim açımdan göstermek için bunun gibi iki model sınıfınız olduğunu söyleyin:

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; }
}

Color özelliğini oluşturmak, gerçek bir ORM için yeterli olacaktır ancak EF için yeterli değildir. Aşağıdaki gibi Thing sınıfındaki Color özelliği için fazladan bir kimlik eklemeniz gerekir:

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

Bir yabancı nesne referansı için fazlalık ID alanını eklemezseniz, bağlantılı sınıftan tüm olası seçeneklerle kolayca açılır listeler oluşturamazsınız.

Bu, bir sınıfın iç işleyişini diğerine güçlü bir şekilde eşleştirdiği için gerçekten korkunç bir tasarım. ColorID hakkında hiçbir şey bilmemeli, Color sınıfı bir eşitlik kontrolünü bile ID'sine sahip olmadan göstermeden kendi eşitlik kontrollerini yapmalı.

Bu en iyi 101 yöntemdir ancak görünüşe göre Microsoft, bilgisayar biliminin ve nesne yönelimli programlamanın temel ilkelerinden tamamen habersizdir. [/ Rant]