ASP.NET MVC สามารถทำอะไรได้บ้างและ Ruby on Rails ไม่สามารถทำได้? [ปิด]

ASP.NET MVC และ Rails มีพื้นที่การใช้งานที่คล้ายกันสร้างขึ้นรอบ ๆ สถาปัตยกรรมเดียวกันทั้งเฟรมเวิร์กค่อนข้างใหม่และโอเพ่นซอร์ส

ดังนั้นในฐานะที่เป็นโปรแกรมเมอร์ Rails ที่ฉันอยากรู้ ASP.NET MVC สามารถทำอะไรได้บ้างและ Ruby on Rails ไม่สามารถทำได้และวีซ่ากลับกัน?

ฉันได้พัฒนาแอพพลิเคชั่นจริงที่มีทั้ง Rails และ ASP.NET MVC แต่คำตอบนี้มาพร้อมกับข้อแม้ที่สำคัญ: ฉันเรียนรู้และพัฒนาด้วย Rails รุ่นก่อน 2 ดังนั้นจึงเป็นไปได้อย่างสมบูรณ์ที่ฉันล้าสมัยอย่างมากกับ ความรู้ทางรถไฟ

ที่ถูกกล่าวว่าฉันไม่คิดว่ามีสิ่งใดที่สามารถทำได้ด้วยหนึ่ง แต่ไม่อื่น ๆ ด้วยข้อกำหนดชุดใด ๆ สำหรับเว็บแอปพลิเคชันคุณควรสามารถสร้างแอปนั้น - อาจมีประสิทธิภาพเท่าเทียมกัน - ด้วย Rails หรือ ASP.NET MVC

มีสองสิ่งที่เรียบร้อย - ที่ดีที่สุดของความรู้ของฉัน - มีอยู่ใน ASP.NET MVC ส่วนใหญ่เป็นเพราะลักษณะของ C # /. NET ตัวอย่างเช่น: เมื่อฉันมีหน้าเว็บที่มีแบบฟอร์มที่ส่งมาฉันจะมีการดำเนินการที่ตรวจสอบเพื่อดูว่ามีการจัดการกับ GET หรือ POST เพื่อตัดสินใจว่าจะทำอย่างไร:

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

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

นี่เป็นตัวอย่างเล็กน้อยของมัน แต่if request.post?รูปแบบนั้นเป็นสิ่งที่พบได้บ่อยมากใน Rails สำหรับกรณีที่ไม่สำคัญรหัสการกระทำอาจมีขนาดใหญ่และยุ่งเหยิงและบ่อยครั้งที่ฉันต้องการให้ฉันปรับโครงสร้างใหม่เป็นวิธีแยกต่างหากอย่างหมดจด ใน ASP.NET MVC ฉันสามารถทำได้:

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

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

ฉันคิดว่าการแยกการจัดการคำขอ GET และ POST ออกจากกันอย่างหมดจดนั้นเป็นเรื่องที่เรียบร้อย ไมล์สะสมของคุณอาจแตกต่างกันไป

อีกสิ่งหนึ่งที่ ASP.NET MVC ทำนั้นยอดเยี่ยมมาก (อีกครั้งในความเห็นของฉัน) ก็เกี่ยวข้องกับการจัดการแบบฟอร์ม POSTS ใน Rails ฉันต้องค้นหาparamsแฮชสำหรับตัวแปรฟอร์มทั้งหมดของฉัน สมมติว่าฉันมีแบบฟอร์มที่มี 'สถานะ' ฟิลด์ 'gonkulated', 'invert' และ '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

แต่ ASP.NET MVC ช่วยให้ฉันสามารถรับค่าฟอร์มทั้งหมดของฉันเป็นพารามิเตอร์ในวิธีการกระทำของฉัน:

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

นี่คือสองสิ่งที่ฉันชอบเกี่ยวกับ ASP.NET MVC หรือ Rails เหตุผลเหล่านี้ไม่เพียงพอสำหรับนักพัฒนาที่มีเหตุผลหรือมีความสามารถในการเลือกกรอบงานหนึ่งกรอบเหนือกรอบอื่น

ข้อดีอย่างหนึ่งของ ASP.NET MVC บนรางคือถ้าคุณต้องการสร้างแอปพลิเคชันใหม่ผ่านฐานข้อมูลที่มีอยู่ Rails 'ActiveRecord มีความเห็นอย่างมากเกี่ยวกับวิธีการจัดโครงสร้างตาราง (ตารางจะต้องมีคอลัมน์จำนวนเต็มหนึ่งคอลัมน์เท่านั้นเป็นคีย์หลักที่เรียกว่า' id 'ฯลฯ ) ดังนั้นหากตารางที่มีอยู่ของคุณไม่สอดคล้องกับการตั้งค่า ActiveRecord มันยากที่จะทำให้ ActiveRecord งาน. แต่การพัฒนาแอพใหม่ด้วย db ใหม่ด้วย ActiveRecord และ Rails นั้นรวดเร็ว!

ASP.NET MVC ไม่มี ORM เริ่มต้น คุณสามารถเลือกกลยุทธ์การเข้าถึงข้อมูลที่ตรงกับความต้องการของคุณ ORM บางอย่างเช่น nhibernate สามารถรองรับฐานข้อมูลเก่าได้ คุณสามารถมีคีย์หลัก guid และอื่น ๆ

มีทางเลือกอื่นสำหรับ Rails ActiveRecord ชื่อDataMapperแต่ฉันไม่ได้ลองเลย

มีการใช้ทั้งสองคำตอบก็คือว่า IMO ASP.NET MVC มีความยืดหยุ่นกว่า Rails ถ้าโปรแกรมของคุณต้องการที่จะทำมากกว่าเพียงแค่การอ่าน / เขียนจากฐานข้อมูล จากประสบการณ์ของฉัน Rails หยุดลงอย่างรวดเร็วและอย่างหนักในนาทีที่คุณแนะนำความซับซ้อนหรือตรรกะชนิดใด ๆ ให้กับแอปพลิเคชันนอกเหนือจากตรรกะ CRUD ที่น่ารำคาญมาก ASP.NET MVC ไม่พบข้อ จำกัด นี้เนื่องจาก "เปิด" มากกว่าเกี่ยวกับสิ่งที่คุณสามารถทำได้

ทุกอย่างเท่าเทียมกันในแอพพลิเคชั่น "Web 2.0" CRUD ไม่มีสิ่งใดที่สามารถทำได้มากกว่าแอพพลิเคชั่นอื่น ๆ แต่สำหรับแอพพลิเคชั่นที่ซับซ้อนมากขึ้นซึ่งต้องการเวิร์กโฟลว์หรือแยกแหล่งข้อมูลหรือโต้ตอบกับแอปพลิเคชันอื่น นั่นไม่ใช่ CRUD ทั่วไป ASP.NET สามารถทำอะไรได้มากกว่าและไม่ จำกัด เหมือน Rails

ฉันไม่เคยทำงานกับ Ruby on Rails ดังนั้นฉันจึงไม่มีคุณสมบัติที่จะตอบคำถามนี้ได้อย่างแน่นอน แต่สิ่งหนึ่งที่ฉันชอบเกี่ยวกับ ASP.NET MVC ก็คือความปลอดภัยของประเภท สิ่งนี้เกิดขึ้น Adam Crossland และ rmac ได้สัมผัสกับมันสั้น ๆ ในความคิดเห็นของพวกเขา แต่ฉันอยากจะชี้ให้เห็นว่าด้วยวิธีการควบคุมดังต่อไปนี้พารามิเตอร์แต่ละตัวจะถูกพิมพ์อย่างยิ่ง สิ่งนี้ทำให้โค้ดภายในเมธอด Edit มีความสะอาดกว่าโดยที่คุณไม่ต้องกังวลกับการแปลงการแทนค่าสตริงให้เป็นตัวแปรที่พิมพ์ได้อย่างถูกต้อง

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

อีกที่หนึ่งความปลอดภัยประเภทนี้ปรากฏขึ้นในมุมมองและมุมมองบางส่วนที่หนึ่งสามารถเชื่อมโยงมุมมองของมุมมองบางส่วนกับวัตถุ C Old แบบเก่าซึ่งจะทำหน้าที่เป็นโมเดลของมุมมองหรือมุมมองบางส่วน สิ่งนี้ทำให้ชีวิตง่ายขึ้นมากโดยเฉพาะอย่างยิ่งที่คุณต้องการสร้างลำดับชั้นของมุมมองที่มีมุมมองอื่น

ถ้าInfinity.ViewModels.Siteเนมสเปซมีคลาสที่เรียกว่าContactViewModelดังนั้นสำหรับมุมมองมีดโกนคุณสามารถทำได้โดยการวางบรรทัดแบบนี้ที่ด้านบนของมุมมอง:

@model Infinity.ViewModels.Site.ContactViewModel

และสำหรับมุมมอง ASPX คุณทำได้โดยการประกาศมุมมองด้วยวิธีนี้:

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

คุณเชื่อมโยงอินสแตนซ์ที่แท้จริงของวัตถุรูปแบบกับมุมมองในวิธีการดำเนินการควบคุมแล้วเข้าถึงอินสแตนซ์ของวัตถุรูปแบบในมุมมองโดยModelคุณสมบัติของมุมมอง

สำหรับฉันแล้วมันยอดเยี่ยมมาก ทีมที่สร้าง ASP.NET MVC ได้ใช้ความพยายามอย่างมากในการสร้างพื้นที่ทั้ง 3 รุ่นมุมมองและตัวควบคุมอย่างมาก

ฉันไม่แน่ใจว่า Ruby-on-Rails มีสิ่งนี้หรือไม่ แต่ฉันก็หวังเช่นนั้น

พวกเขาคล้ายกันมากและพวกเขาทุกคนสามารถ "ทำสิ่งเดียวกัน" ส่วนใหญ่เพียงแค่บางสิ่งนั้นทำได้ง่ายกว่าและยากกว่า

ฉันใช้ ASP.NET MVC รอบ ๆ รีลีสดั้งเดิมและแน่นอนว่า Rails clone ลบ activerecord ดังนั้น Rails เกือบจะมีชุดคุณลักษณะที่ใหญ่กว่ามากและมีระบบปลั๊กอิน / อัญมณีขนาดใหญ่กว่ามาก

จากประสบการณ์ที่ จำกัด ของฉันข้อดีหลักของ ASP.NET MVC ก็คือมันเป็นภาษาที่รวบรวม สิ่งนี้ช่วยให้คุณสามารถตรวจจับข้อบกพร่องในการเขียนโปรแกรมบางอย่างที่มีการรวบรวมอยู่แล้วโดยที่ Ruby จะต้องพึ่งพาการตรวจจับในระหว่างการทดสอบหน่วย

ความจริงที่ว่ามันถูกคอมไพล์ทำให้สามารถมีเครื่องมือการรีแฟคเตอร์ขั้นสูงเช่นเปลี่ยนชื่อของคุณสมบัติในที่เดียวและการอ้างอิงทั้งหมดไปยังคุณสมบัตินั้นเปลี่ยนไป อย่างน้อยที่สุดก็ไม่สามารถทำได้ใน TextMate ซึ่งผู้พัฒนา Rails จำนวนมากใช้

ในทางตรงกันข้ามข้อดีหลักของ Ruby on Rails ก็คือมันเป็นภาษาที่ตีความ;) ธรรมชาติของ Ruby, วิธีที่คุณสามารถปรับเปลี่ยนวัตถุใด ๆ ในหน่วยความจำหรือชั้นเรียนของลิงสามารถนำไปสู่การแก้ปัญหาที่หรูหรามาก; ตรวจสอบหนังสือEloquent Rubyสำหรับตัวอย่าง และเฟรมเวิร์คของ Rails นั้นขึ้นอยู่กับความสามารถนี้

ความสามารถในการแทนที่วิธีการที่วัตถุใด ๆ ได้ตลอดเวลาได้ช่วยฉันอย่างมากในการเขียนการทดสอบหน่วย ใน. NET, Dependency Injection และ IOC container นั้นเป็นข้อกำหนดสำหรับการสร้างรหัสที่สามารถทดสอบได้ นั่นไม่จำเป็นใน Ruby

แก้ไข:

หลังจากคิดเกี่ยวกับมันน่าจะเป็นคุณสมบัตินักฆ่าของ Rails คือการย้ายฐานข้อมูล กรอบงาน ASP.NET MVC ไม่ได้ให้การสนับสนุนฐานข้อมูลใด ๆ กรอบงาน. NET มีองค์ประกอบการเข้าถึงข้อมูล / ORM เช่น Entity Framework และ Linq ถึง Sql แต่มันไม่มีเครื่องมือใด ๆ สำหรับการออกแบบโครงสร้างฐานข้อมูล

หากคุณจ่ายสำหรับ VS เวอร์ชันที่แพงกว่าคุณสามารถรับData Dudeซึ่งช่วยให้คุณออกแบบ schema ของฐานข้อมูลและมีเครื่องมือบางอย่างสำหรับการปรับใช้ schema กับฐานข้อมูล แต่เท่าที่ฉันสามารถบอกได้การสนับสนุนสำหรับการจัดการการย้ายข้อมูลจากแอปพลิเคชันรุ่นก่อนหน้านั้นมี จำกัด มาก

บางคนอ้างว่า ASP.NET MVC ไม่ใช่กรอบงาน MVC จริงๆเป็นเพียงกรอบ VC เนื่องจากการขาดการสนับสนุนสำหรับการย้ายฐานข้อมูล

แก้ไข (อีกครั้ง):

การเปลี่ยนแปลงใน Visual Studio toolchain / EF ได้แนะนำการโยกย้ายโดยใช้รหัสตั้งแต่การแก้ไขครั้งล่าสุดของฉัน (แต่ตรวจสอบ FluentMigrator หากคุณกำลังจะลงเส้นทางนั้น)

ปัญหาหลักของฉันกับ MVC 3 และ Entity Framework ของ Microsoft คือหลักการออกแบบที่ไม่ดี

หนึ่งในปัญหาแรกที่ฉันพบคือเมื่อใช้คลาสอื่นเป็นคุณสมบัติและพยายามสร้างรายการแบบหล่นลงสำหรับค่าที่เป็นไปได้

เพื่อแสดงจุดของฉันบอกว่าคุณมีสองรุ่นคลาสเช่นนี้:

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

การสร้างคุณสมบัติสีจะเพียงพอสำหรับ ORM จริง แต่ไม่ใช่ EF คุณต้องเพิ่ม ID ซ้ำซ้อนสำหรับคุณสมบัติ Color ในคลาส Thing ดังนี้:

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

หากคุณไม่เพิ่มฟิลด์ ID ซ้ำซ้อนสำหรับการอ้างอิงวัตถุต่างประเทศคุณไม่สามารถสร้างรายการแบบเลื่อนลงได้อย่างง่ายดายด้วยตัวเลือกที่เป็นไปได้ทั้งหมดจากคลาสที่เชื่อมโยง

นี่คือการออกแบบที่แย่มากเพราะมันแสดงให้เห็นถึงการทำงานภายในของชั้นหนึ่งไปอีกชั้นหนึ่งอย่างยิ่ง สิ่งที่ไม่ควรรู้เกี่ยวกับ ColorID คลาส Color ควรจัดการการตรวจสอบความเท่าเทียมกันของตัวเองโดยไม่ต้องเปิดเผยว่ามี ID

นี่เป็นแนวทางปฏิบัติที่ดีที่สุด 101 สิ่ง แต่เห็นได้ชัดว่า Microsoft ไม่ได้ตระหนักถึงหลักการพื้นฐานของวิทยาศาสตร์คอมพิวเตอร์และการเขียนโปรแกรมเชิงวัตถุ [/ คุยโม้]