ASP.NET MVC có thể làm gì và Ruby on Rails không thể? [đóng cửa]

ASP.NET MVC và Rails có diện tích sử dụng tương tự nhau, được xây dựng xung quanh cùng một kiến ​​trúc, cả hai khung tương đối mới và nguồn mở.

Vì vậy, với tư cách là một lập trình viên Rails tôi muốn biết, ASP.NET MVC có thể làm gì và Ruby on Rails không thể, và ngược lại?

Tôi đã phát triển các ứng dụng thực tế với cả Rails và ASP.NET MVC, nhưng câu trả lời này đi kèm với một cảnh báo quan trọng: Tôi đã học và phát triển với Rails phiên bản 2 trước, vì vậy tôi hoàn toàn có thể lỗi thời với tôi Rails kiến ​​thức.

Điều đó đang được nói, tôi không nghĩ rằng có bất cứ điều gì có thể được thực hiện với một nhưng không phải là khác. Đưa ra bất kỳ yêu cầu nào cho một ứng dụng web, bạn sẽ có thể xây dựng ứng dụng đó - có thể hiệu quả tương đương - với Rails hoặc ASP.NET MVC.

Có một vài điều thú vị - theo hiểu biết tốt nhất của tôi - có sẵn trong ASP.NET MVC chủ yếu là do các khía cạnh của C # /. NET. Ví dụ: khi tôi có một trang chứa biểu mẫu được gửi, tôi sẽ có một Hành động kiểm tra xem liệu nó đang xử lý GET hay POST để quyết định phải làm gì:

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

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

Đây là một ví dụ tầm thường của nó, nhưng if request.post?mẫu này là một mẫu cực kỳ phổ biến trong Rails. Đối với các trường hợp không tầm thường, mã Hành động có thể trở nên lớn và lộn xộn, và thông thường, tôi ước rằng tôi có thể cấu trúc lại nó thành các phương thức riêng biệt một cách sạch sẽ. Trong ASP.NET MVC tôi có thể làm điều đó:

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

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

Tôi nghĩ rằng việc có thể phân tách rõ ràng việc xử lý các yêu cầu GET và POST là gọn gàng. Số dặm của bạn có thể thay đổi.

Một điều khác mà ASP.NET MVC thực hiện đó là siêu tuyệt vời (một lần nữa theo ý kiến ​​của tôi) cũng liên quan đến việc xử lý mẫu POSTS. Trong Rails, tôi phải truy vấn paramshàm băm cho tất cả các biến mẫu của tôi. Hãy nói rằng tôi có một biểu mẫu với các trường 'trạng thái', 'được cộng hưởng', 'đảo ngược' và 'bố trí':

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

Nhưng ASP.NET MVC gọn gàng cho phép tôi lấy tất cả các giá trị biểu mẫu của mình làm tham số cho phương thức Hành động của mình:

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

Đó là hai điều mà tôi thực sự yêu thích về ASP.NET MVC hoặc Rails. Chúng không đủ lý do để bất kỳ nhà phát triển lành mạnh hoặc có thẩm quyền nào chọn một khung trên khung kia.

Một lợi thế của ASP.NET MVC so với Rails là nếu bạn cần xây dựng một ứng dụng mới qua cơ sở dữ liệu hiện có. ActiveRecord của Rails rất quan tâm về cách cấu trúc các bảng (bảng phải có một và chỉ một cột số nguyên làm khóa chính gọi là 'id', v.v.) vì vậy nếu các bảng hiện tại của bạn không tuân theo tùy chọn ActiveRecord, thật khó để tạo ActiveRecord công việc. Nhưng phát triển ứng dụng mới với db mới với ActiveRecord và Rails thì nhanh!

ASP.NET MVC không có ORM mặc định. Bạn có thể chọn một chiến lược truy cập dữ liệu phù hợp với nhu cầu của bạn. Một số ORM như nhibernate có thể hỗ trợ cơ sở dữ liệu cũ. Bạn có thể có khóa chính hướng dẫn, v.v.

Có một phiên bản thay thế cho Rails ActiveRecord được gọi là DataMapper , nhưng tôi chưa thử.

Đã sử dụng cả hai, câu trả lời IMO là ASP.NET MVC linh hoạt hơn Rails nếu ứng dụng của bạn cần làm nhiều hơn là chỉ đọc / ghi từ cơ sở dữ liệu. Theo kinh nghiệm của tôi, Rails bị hỏng nhanh chóng và nặng nề ngay khi bạn giới thiệu bất kỳ loại phức tạp hoặc logic nào cho ứng dụng ngoài logic CRUD rất tầm thường. ASP.NET MVC không gặp phải hạn chế này vì nó "cởi mở" hơn về những gì bạn có thể làm.

Tất cả những thứ khác đều bằng nhau trong một ứng dụng CRUD "Web 2.0" thông thường, không có gì người ta có thể làm so với ứng dụng khác, nhưng đối với một ứng dụng phức tạp hơn cần một quy trình làm việc, hoặc phân biệt nguồn dữ liệu hoặc để tương tác với ứng dụng khác hoặc bất cứ điều gì Đó không phải là CRUD điển hình, ASP.NET có thể làm được nhiều hơn và không bị hạn chế như Rails.

Tôi chưa bao giờ làm việc với Ruby on Rails, vì vậy tôi không đủ điều kiện để trả lời câu hỏi này, nhưng một điều tôi thích về ASP.NET MVC vô cùng là sự an toàn kiểu. Điều này đến trong cách. Adam Crossland và rmac đã chạm vào nó một cách ngắn gọn trong các bình luận của họ, nhưng tôi muốn chỉ ra rằng với một phương thức điều khiển như sau, mỗi tham số sẽ được gõ mạnh. Điều này làm cho mã trong phương thức Chỉnh sửa sạch hơn rất nhiều ở chỗ bạn không phải lo lắng về việc chuyển đổi các biểu diễn chuỗi thành các biến được nhập đúng.

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

Một vị trí khác mà loại an toàn này hiển thị là trong Chế độ xem và Chế độ xem một phần trong đó người ta có thể liên kết chế độ xem một phần với đối tượng C # cũ, sẽ đóng vai trò là mô hình của Chế độ xem hoặc Chế độ xem một phần. Điều này làm cho cuộc sống dễ dàng hơn nhiều, đặc biệt là nơi bạn muốn xây dựng một hệ thống phân cấp các chế độ xem có chứa các chế độ xem khác.

Nếu Infinity.ViewModels.Sitelà không gian tên chứa một lớp được gọi ContactViewModel, thì đối với các khung nhìn của Dao cạo, bạn làm điều đó bằng cách đặt một dòng như thế này ở trên cùng của khung nhìn:

@model Infinity.ViewModels.Site.ContactViewModel

và đối với các chế độ xem ASPX, bạn thực hiện bằng cách khai báo chế độ xem theo cách này:

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

Bạn liên kết thể hiện thực của đối tượng mô hình với khung nhìn trong phương thức hành động của Trình điều khiển và sau đó truy cập vào thể hiện của đối tượng mô hình trong khung nhìn theo thuộc Modeltính của khung nhìn.

Đối với tôi, kiểu đánh máy mạnh mẽ này là siêu tuyệt vời. Nhóm đã tạo ra ASP.NET MVC đã dành rất nhiều nỗ lực để làm cho mỗi trong số 3 khu vực Mô hình, Chế độ xem và Trình điều khiển được gõ mạnh.

Tôi không chắc liệu Ruby-on-Rails có thứ này không, nhưng tôi sẽ hy vọng như vậy.

Chúng rất giống nhau và hầu hết đều có thể "làm những việc giống nhau", chỉ một số thứ dễ hơn trong một và khó hơn những thứ khác.

Tôi đã sử dụng ASP.NET MVC xung quanh bản phát hành gốc và nó chắc chắn là một bản sao Rails trừ Activerecord. Vì vậy, Rails gần như chắc chắn có một bộ tính năng lớn hơn nhiều và hệ sinh thái plugin / đá quý lớn hơn nhiều.

Theo kinh nghiệm hạn chế của tôi, lợi thế chính của ASP.NET MVC là nó là một ngôn ngữ được biên dịch. Điều này cho phép bạn phát hiện một số lỗi lập trình đã có trong quá trình biên dịch, trong đó Ruby phải dựa vào việc phát hiện sau đó trong quá trình kiểm tra đơn vị.

Ngoài ra, thực tế là nó được biên dịch cho phép có các công cụ tái cấu trúc nâng cao, ví dụ thay đổi tên của một thuộc tính ở một nơi và tất cả các tham chiếu đến thuộc tính được thay đổi. Điều này ít nhất không thể được thực hiện trong TextMate, mà nhiều nhà phát triển Rails sử dụng.

Mặt khác, ưu điểm chính của Ruby on Rails là nó là ngôn ngữ được dịch;) Bản chất của Ruby, làm thế nào bạn có thể sửa đổi bất kỳ đối tượng nào trong bộ nhớ hoặc khỉ vá một lớp, có thể dẫn đến một số giải pháp rất thanh lịch; kiểm tra cuốn sách Eloquent Ruby để biết một số ví dụ. Và rất nhiều khung Rails tự nó dựa trên khả năng này.

Khả năng thay thế bất kỳ phương pháp nào tại bất kỳ đối tượng nào vào bất kỳ lúc nào cũng giúp tôi rất nhiều trong việc viết bài kiểm tra đơn vị. Trong .NET, các thùng chứa Dependency Injection và IOC hầu như là các yêu cầu để tạo mã có thể kiểm tra. Điều đó là không cần thiết trong Ruby.

Chỉnh sửa:

Sau khi suy nghĩ về nó, có lẽ tính năng sát thủ của Rails là di chuyển cơ sở dữ liệu. Khung ASP.NET MVC tự nó không cung cấp bất kỳ hỗ trợ cơ sở dữ liệu nào. .NET framework có một số thành phần truy cập dữ liệu / ORM, ví dụ Entity Framework và Linq to Sql. Nhưng nó không có bất kỳ công cụ nào để thiết kế cấu trúc cơ sở dữ liệu.

Nếu bạn trả tiền cho một trong những phiên bản đắt hơn của VS, bạn có thể lấy Data Dude , cho phép bạn thiết kế lược đồ cơ sở dữ liệu và có một số công cụ để triển khai lược đồ vào cơ sở dữ liệu. Nhưng theo như tôi có thể nói, hỗ trợ xử lý việc di chuyển từ các phiên bản trước của ứng dụng là rất hạn chế.

Một số người cho rằng ASP.NET MVC không thực sự là khung MVC, chỉ đơn thuần là khung VC, do thiếu hỗ trợ cho việc di chuyển cơ sở dữ liệu.

Chỉnh sửa (một lần nữa):

Các thay đổi đối với công cụ Visual Studio / EF đã giới thiệu các lần di chuyển dựa trên mã kể từ lần chỉnh sửa cuối cùng của tôi. (nhưng cũng kiểm tra FluentMigrator nếu bạn đang đi xuống con đường đó)

Vấn đề lớn của tôi với Microsoft MVC 3 và Entity Framework là các nguyên tắc thiết kế tồi tệ đáng kinh ngạc của họ.

Một trong những vấn đề đầu tiên tôi gặp phải là khi sử dụng một lớp khác làm tài sản và cố gắng tạo một danh sách thả xuống cho các giá trị có thể.

Để minh họa quan điểm của tôi nói rằng bạn có hai lớp mô hình như thế này:

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

Tạo thuộc tính Màu sẽ đủ cho ORM thực chứ không phải EF. Bạn phải thêm ID dự phòng cho thuộc tính Color trong lớp Thing như vậy:

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

Nếu bạn không thêm trường ID dự phòng cho tham chiếu đối tượng nước ngoài, bạn không thể dễ dàng tạo danh sách thả xuống với tất cả các tùy chọn có thể từ lớp được liên kết.

Đây thực sự là một thiết kế khủng khiếp vì nó kết hợp mạnh mẽ các hoạt động nội bộ của lớp này với lớp khác. Không nên biết gì về ColorID, lớp Color sẽ xử lý các kiểm tra tính bằng của chính nó mà không để lộ rằng nó thậm chí còn có ID.

Đây là cách thực hành tốt nhất 101 công cụ nhưng rõ ràng Microsoft hoàn toàn không biết về các nguyên tắc cơ bản của khoa học máy tính và lập trình hướng đối tượng. [/ Rant]