Apa yang bisa dilakukan ASP.NET MVC dan Ruby on Rails tidak bisa? [Tutup]


37

ASP.NET MVC dan Rails memiliki area penggunaan yang serupa, dibangun dengan arsitektur yang sama, kedua kerangka kerja tersebut relatif baru dan open source.

Jadi sebagai programmer Rails saya ingin tahu, apa yang bisa dilakukan ASP.NET MVC dan Ruby on Rails tidak bisa, dan sebaliknya?


Pertanyaan bagus Saya seorang pengembang MVC dan ingin tahu jawabannya.
StuperUser

14
Jenis pertanyaan ini bersifat terbuka dan lebih baik dijawab dengan memutar web IMHO. Apa yang bisa dilakukan BMW 335 yang tidak bisa dilakukan Hyundai Sonata? Keduanya memiliki 4 percobaan, setir dan dibangun pada kerangka konsumsi yang sama; bahan bakar. Pertanyaan-pertanyaan ini muncul karena kurangnya penelitian tentang pemahaman tentang topik yang diberikan yang dapat memfasilitasi pertanyaan yang lebih langsung .... Saya yakin banyak yang akan tidak setuju karena ini adalah programmer ...
Aaron McIver

1
@ Harun - Meskipun saya mengalami kesulitan menambahkan jawaban untuk pertanyaan ini, saya setuju dengan Anda pada prinsipnya, dan saya harap saya menjelaskan bahwa untuk meminjam analog Anda, kami membandingkan satu mobil dengan yang lain.
Adam Crossland

10
Saya pribadi berpikir itu adalah pertanyaan yang valid. Pertanyaan-pertanyaan seperti itu seharusnya tidak dihilangkan begitu mudah karena banyak dari kita hanya tahu satu sisi dari cerita dan itu membantu untuk mendapatkan ide dari sisi lain juga. BTW, mengajukan pertanyaan tentang StackExchange memenuhi syarat sebagai penelitian dalam buku saya.
Umar Farooq Khawaja

3
Saya sering mengajukan pertanyaan seperti ini dan meminta mereka untuk turun, jadi saya ingin menunjukkan dukungan di sini untuk OP. Keputusan yang diambil ketika coding hampir selalu subyektif. Hak saya bisa salah Anda, sementara keduanya bisa mengembangkan solusi kerja yang setara (subjektif). Dalam hal ini OP menginginkan pendapat tentang manfaat relatif dari dua teknologi yang berlawanan. Anda tidak akan menemukan informasi itu di mana pun kecuali di benak orang-orang yang telah melalui proses praktis memilih satu dari yang lain. Oleh karena itu pertanyaan yang sah.
Ian

Jawaban:


31

Saya telah mengembangkan aplikasi nyata dengan Rails dan ASP.NET MVC, tetapi jawaban ini datang dengan peringatan yang signifikan: Saya belajar dan mengembangkan dengan Rails pra-versi 2, jadi sangat mungkin bahwa saya jauh ketinggalan zaman dengan saya Pengetahuan rel.

Yang sedang berkata, saya tidak berpikir bahwa ada sesuatu yang dapat dilakukan dengan satu tetapi tidak yang lain. Dengan serangkaian persyaratan untuk aplikasi web, Anda harus dapat membangun aplikasi itu - mungkin sama efisiennya - dengan Rails atau ASP.NET MVC.

Ada beberapa hal rapi yang - sepengetahuan saya - tersedia di ASP.NET MVC terutama karena aspek C # /. NET. Misalnya: ketika saya memiliki halaman yang berisi formulir yang dikirimkan, saya akan memiliki Tindakan yang memeriksa untuk melihat apakah itu berurusan dengan GET atau POST untuk memutuskan apa yang harus dilakukan:

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

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

Ini adalah contoh sepele dari itu, tetapi if request.post?polanya sangat umum di Rails. Untuk kasus-kasus non-sepele, kode Aksi bisa menjadi besar dan berantakan, dan seringkali, saya berharap bahwa saya bisa mengubahnya menjadi metode terpisah secara bersih. Dalam ASP.NET MVC saya dapat melakukan itu:

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

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

Saya pikir bisa memisahkan penanganan GET dan POST dengan rapi. Jarak tempuh Anda mungkin beragam.

Hal lain yang dilakukan ASP.NET MVC yang sangat keren (sekali lagi menurut saya) juga terkait dengan penanganan formulir POS. Di Rails, saya harus meminta paramshash untuk semua variabel formulir saya. Katakanlah saya memiliki formulir dengan bidang 'status', 'gonkulated', 'invert' dan 'disposisi':

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

Tetapi ASP.NET MVC memungkinkan saya untuk mendapatkan semua nilai formulir saya sebagai parameter untuk metode Tindakan saya:

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

Itulah dua hal yang sangat saya sukai tentang ASP.NET MVC atau Rails. Mereka tidak cukup alasan untuk pengembang waras atau kompeten untuk memilih satu kerangka kerja dari yang lain.


6
Mengenai parameter tindakan: Saya akan berpikir itu public ActionResult Edit(Foothing foothing), yaitu fitur ModelBinder bahkan lebih rapi.
rmac

10
Contoh rel sudah ketinggalan zaman. Mereka bekerja, tetapi ada cara yang lebih baik untuk melakukan ini.
Jason w

2
@Jason: maukah Anda memperluas ini dan mungkin memposting inti ?
Dan

3
Saya setuju bahwa request.post? terlihat tidak biasa bagi saya juga (mungkin karena itu digunakan dalam versi yang lebih lama). Saya mulai dengan Rails 3 dan metode edit selalu 'dapatkan'. Saya kira Anda bisa mengkonfigurasinya menjadi posting, tetapi Rails menggunakan pola RESTful yang akan menggunakan metode 'pembaruan' untuk melakukan posting terhadap setiap perubahan yang akan terjadi dalam model. Jadi, jika dilakukan dengan benar, Anda bahkan tidak perlu memeriksa apakah metode 'edit' adalah sebuah posting.
PhillipKregg

3
Memilih Anda hanya karena Anda mengajukan argumen yang masuk akal. Saya lebih suka Rails, tetapi sepenuhnya subjektif dan Anda membantah kasus Anda dengan baik.
Steve Hill

6

Salah satu keunggulan ASP.NET MVC daripada Rails adalah jika Anda perlu membangun aplikasi baru di atas basis data yang ada. ActiveRecord Rails sangat berpendapat tentang bagaimana tabel harus disusun (tabel harus memiliki satu dan hanya satu kolom integer sebagai kunci utama yang disebut 'id', dll) jadi jika tabel Anda yang ada tidak sesuai dengan preferensi ActiveRecord, sulit untuk membuat ActiveRecord kerja. Tetapi mengembangkan aplikasi baru dengan db baru dengan ActiveRecord dan Rails cepat!

ASP.NET MVC tidak memiliki ORM default. Anda dapat memilih strategi akses data yang sesuai dengan kebutuhan Anda. Beberapa ORM seperti nhibernate dapat mendukung basis data lama. Anda dapat memiliki kunci utama panduan, dll.

Ada alternatif untuk Rails ActiveRecord yang disebut DataMapper , tetapi saya belum mencobanya.


9
ActiveRecord Ruby memang memungkinkan Anda untuk menghilangkan banyak kode jika Anda mengikuti konvensi tertentu, tetapi itu tidak diperlukan. Jika konvensi tidak diikuti, maka Anda harus lebih eksplisit.
kevin cline

1
ASP.NET MVC memiliki Entity Framework untuk ORM, yang sejauh ini cukup luar biasa dalam pengalaman saya dengannya.
Cooper

Jika maksud Anda mengeksekusi query yang dihasilkan dengan buruk 20 kali lebih lambat daripada SQL yang ditulis dengan benar maka ya;) ... Dapper Contrib adalah sesuatu yang saya temukan hebat & cepat ...
niico

2

Setelah menggunakan keduanya, jawabannya IMO adalah bahwa ASP.NET MVC lebih fleksibel daripada Rails jika aplikasi Anda perlu melakukan lebih dari sekadar membaca / menulis dari database. Dalam pengalaman saya Rails rusak dengan cepat dan berat begitu Anda memperkenalkan segala jenis kompleksitas atau logika untuk aplikasi di luar logika CRUD yang sangat sepele. ASP.NET MVC tidak menemukan batasan ini karena ini lebih "terbuka" tentang apa yang dapat Anda lakukan.

Semua hal lain dianggap sama dalam aplikasi CRUD "Web 2.0" yang khas, tidak ada yang dapat dilakukan oleh orang lain, tetapi untuk aplikasi yang lebih rumit yang memerlukan alur kerja, atau sumber data yang berbeda, atau untuk berinteraksi dengan aplikasi lain, atau apa pun itu bukan tipikal CRUD, ASP.NET dapat melakukan lebih banyak dan tidak membatasi seperti Rails.


9
-1 Saya tidak melihat alasan mengapa ASP.NET MVC akan dianggap lebih fleksibel - jika Anda melihat komponen utama, perutean, pengontrol, rendering, mereka semua hanya merobek rel dan kehilangan banyak fitur juga.
scottschulthess

1
Bagaimana asp.net mvc 'lebih terbuka'? Saya dapat melewatkan seluruh hal perancah crud, dan membuat model dan pengontrol saya dari awal plus membuat asosiasi bersarang - satu ke banyak, banyak ke satu, banyak ke banyak - tanpa ada 'kerusakan'. Dan, jika saya memutuskan untuk menggunakan front-end javascript yang berat, saya dapat dengan mudah mengirim semua data model saya ke klien di JSON (atau XML, atau format lainnya). Plus, jika Anda bisa memikirkan fungsionalitas yang ingin Anda terapkan, daripada mungkin sudah ada permata untuk itu. Tidak sulit menemukan aplikasi Rails non-sepele.
PhillipKregg

2
Mampu drop down ke raw c # / .net framework bisa dianggap lebih fleksibel?
Chris Barry

2
Sangat terlambat dalam hal ini, tetapi apa yang saya maksud dengan posting ini adalah ASP.NET MVC memungkinkan Anda beralih ke C # /. NET dan memanfaatkan seluruh kerangka kerja. Rails pada saat itu (sekitar 2.0 saya pikir? Saya tidak ingat) pada dasarnya membuat CRUD sangat mudah dan yang lainnya sulit; proyek yang saya kerjakan ketika saya menulis ini dilakukan di Rails (kesalahan saya) dan rusak saat kami melakukan logika di luar "membaca dari database, menampilkan di halaman", seandainya saya melakukannya di C # / ASP.NET MVC ( 1.0 pada titik ini IIRC) Saya tidak akan menemui banyak masalah yang saya lakukan dengan memilih Rails untuk aplikasi sebagai gantinya.
Wayne Molina

2

Saya tidak pernah bekerja dengan Ruby on Rails, jadi saya tidak cukup memenuhi syarat untuk menjawab pertanyaan ini, tetapi satu hal yang saya sukai dari ASP.NET MVC adalah keamanannya. Ini menghalangi. Adam Crossland dan rmac menyentuhnya secara singkat dalam komentar mereka, tetapi saya ingin menunjukkan bahwa dengan metode pengontrol seperti berikut ini, masing-masing parameter akan diketik dengan kuat. Ini membuat kode dalam metode Edit jauh lebih bersih karena Anda tidak perlu khawatir tentang mengubah representasi string menjadi variabel yang diketik dengan benar.

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

Tempat lain keamanan jenis ini muncul adalah di Tampilan dan Tampilan Parsial di mana orang dapat mengaitkan tampilan sebagian dengan objek C # Lama Biasa, yang akan berfungsi sebagai model Tampilan atau Tampilan Parsial itu. Ini membuat hidup jauh lebih mudah, terutama di mana Anda ingin membangun hierarki pandangan yang mengandung pandangan lain.

Jika Infinity.ViewModels.Sitenamespace berisi kelas yang disebut ContactViewModel, maka untuk tampilan Razor, Anda melakukannya dengan menempatkan garis seperti ini di bagian atas tampilan:

@model Infinity.ViewModels.Site.ContactViewModel

dan untuk tampilan ASPX, Anda melakukannya dengan mendeklarasikan tampilan seperti ini:

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

Anda mengaitkan instance sebenarnya dari objek model dengan tampilan dalam metode tindakan Controller dan kemudian mengakses instance objek model dalam tampilan dengan Modelproperti tampilan.

Bagi saya, ketikan yang kuat ini sangat keren. Tim yang menciptakan ASP.NET MVC telah menghabiskan banyak upaya untuk membuat masing-masing dari 3 area Model, View, dan Controller diketik dengan kuat.

Saya tidak yakin apakah Ruby-on-Rails memiliki ini, tapi saya harap begitu.


Bahasa Ruby juga sangat diketik (juga diketik bebek). Dan Rails menggunakan catatan aktif untuk secara otomatis mengaitkan modelnya dengan pandangannya. Anda tidak perlu mendeklarasikannya di controller. Jika Anda ingin membuat hierarki tampilan bersarang, Anda akan membuat variabel instan di controller yang mewakili model yang Anda ingin diteruskan ke tampilan. Jadi ya, keduanya bisa melakukan hal yang sama.
PhillipKregg

1

Mereka sangat mirip, dan mereka semua dapat "melakukan hal yang sama" sebagian besar, hanya beberapa hal yang lebih mudah dalam satu dan lebih keras daripada yang lain.

Saya menggunakan ASP.NET MVC di sekitar rilis asli dan itu jelas merupakan Rails clone minus activerecord. Jadi, Rails hampir pasti memiliki fitur yang jauh lebih besar dan ekosistem plugin / permata yang jauh lebih besar.


2
Benar - tetapi Rails juga telah ada selama sekitar 8 tahun sehingga memiliki awal yang baik. Saya datang dari Rails ke asp.net dan MVC 3 sebenarnya sangat bagus. Kerangka Entity dan manajer paket NuGet sejauh ini sangat mengesankan bagi saya.
PhillipKregg

1

Dalam pengalaman saya yang terbatas, keuntungan utama ASP.NET MVC adalah bahasa yang dikompilasi. Ini memungkinkan Anda untuk mendeteksi beberapa bug pemrograman yang sudah dikompilasi, di mana Ruby harus mengandalkan pendeteksian selama pengujian unit.

Juga fakta bahwa itu dikompilasi memungkinkan untuk memiliki alat refactoring canggih, misalnya mengubah nama properti di satu tempat, dan semua referensi ke properti diubah. Setidaknya ini tidak bisa dilakukan di TextMate, yang banyak digunakan pengembang Rails.

Di sisi lain, keuntungan utama Ruby on Rails adalah bahwa itu adalah bahasa yang ditafsirkan;) Sifat Ruby, bagaimana Anda dapat memodifikasi objek apa pun dalam memori, atau menambal monyet kelas, dapat menyebabkan beberapa solusi yang sangat elegan; lihat buku Eloquent Ruby untuk beberapa contoh. Dan banyak kerangka Rails sendiri didasarkan pada kemampuan ini.

Kemampuan untuk mengganti metode apa pun pada objek apa saja kapan saja juga sangat membantu saya dalam menulis unit test. Dalam .NET, Dependency Injection dan kontainer IOC sebenarnya merupakan persyaratan untuk membuat kode yang dapat diuji. Itu tidak perlu di Ruby.

Edit:

Setelah memikirkannya, mungkin fitur pembunuh Rails adalah migrasi basis data. Kerangka kerja ASP.NET MVC tidak dengan sendirinya menyediakan dukungan basis data apa pun. Framework .NET memang memiliki beberapa komponen akses data / ORM, misalnya Entity Framework dan Linq to Sql. Tetapi tidak memiliki alat untuk merancang struktur database.

Jika Anda membayar untuk salah satu versi VS yang lebih mahal, Anda bisa mendapatkan Data Dude , yang memungkinkan Anda merancang skema basis data, dan memiliki beberapa alat untuk menyebarkan skema ke basis data. Tetapi sejauh yang saya tahu, dukungan untuk menangani migrasi dari versi aplikasi yang lebih lama sangat terbatas.

Beberapa mengklaim bahwa ASP.NET MVC sebenarnya bukan kerangka kerja MVC, hanya kerangka kerja VC, karena kurangnya dukungan untuk migrasi database.

Edit (lagi):

Perubahan pada toolchain Visual Studio / EF telah memperkenalkan migrasi berbasis kode sejak edit terakhir saya. (tetapi juga periksa FluentMigrator jika Anda akan turun jalan itu)


2
Entity Framework 5.0 Code First mendukung Migrations
hofnarwillie

Sebenarnya, migrasi kode pertama telah didukung sejak 4.1, yang merupakan AFAIK dirilis tidak terlalu lama setelah saya edit.
Pete

-1

Masalah utama saya dengan Microsoft MVC 3 dan Entity Framework adalah prinsip-prinsip desain mereka yang buruk.

Salah satu masalah pertama yang saya temui adalah ketika menggunakan kelas lain sebagai properti dan mencoba membuat daftar dropdown untuk nilai yang mungkin.

Untuk menggambarkan maksud saya katakan Anda memiliki dua kelas model seperti ini:

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

Menciptakan properti Warna akan cukup untuk ORM nyata tetapi tidak EF. Anda harus menambahkan ID yang berlebihan untuk properti Color di kelas Thing seperti:

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

Jika Anda tidak menambahkan bidang ID berlebihan untuk referensi objek asing, Anda tidak dapat dengan mudah membuat daftar dropdown dengan semua opsi yang mungkin dari kelas yang ditautkan.

Ini benar-benar desain yang mengerikan karena sangat memadukan pekerjaan internal dari satu kelas ke kelas lainnya. Seharusnya tidak tahu apa-apa tentang ColorID, kelas Warna harus menangani pemeriksaan kesetaraan sendiri tanpa memperlihatkan bahwa ia bahkan memiliki ID.

Ini adalah praktik terbaik 101 hal, tetapi tampaknya Microsoft sama sekali tidak menyadari prinsip dasar ilmu komputer dan pemrograman berorientasi objek. [/ Rant]


8
Anda tidak memerlukan properti kunci asing di objek kerangka kerja entitas Anda. Selain itu, EF adalah produk yang sepenuhnya terpisah dan tidak terintegrasi dengan ASP.NET MVC dengan cara apa pun. Anda harus menggunakan model tampilan untuk membangun antarmuka pengguna Anda dan membuat daftar drop-down atau kontrol lainnya.
Lucifer Sam

Saya setuju. Anda seharusnya tidak memiliki kunci ID sama sekali dalam kerangka entitas Anda. ORM harus menangani identitas objek. Tapi poin diambil; Saya benar-benar mengeluh tentang EF ORM yang mengerikan. Contoh itu adalah versi sederhana yang datang langsung dari Microsoft. Itulah tepatnya yang mereka lakukan dalam contoh ContosoUniversity mereka. Ini memang maksud saya. Microsoft tidak tahu bagaimana melakukan MVC atau ORM dan contoh mereka menunjukkannya.
Mike Bethany

1
Menambahkan properti ColorID memungkinkan Anda menerapkan pola lazy loading yang sangat berguna di saat-saat tertentu. Misalnya, jika objek yang direferensikan sangat besar dan Anda tidak benar-benar membutuhkan semua nilai properti objek, maka itu akan membuang-buang waktu pemrosesan untuk mengambil semuanya hanya untuk menemukan bagian ID yang terkait dengannya (ColorID) . Ini juga memungkinkan Anda untuk menerapkan kunci asing Nullable / Non-Nullable, yaitu bagaimana jika Warna tidak selalu dibutuhkan? Ubah ColorID ke Integer Nullableint?
hofnarwillie
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.