it-swarm-vi.com

ASP.NET MVC có thể làm gì và Ruby trên Rails không thể?

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 Rails lập trình viên 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?

37
Nikita Barsukov

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ể hết hạn với kiến ​​thức Rails của tôi.

Đ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 cái này nhưng không phải cái kia. Đư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 có chứa một 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 a POST để quyết định 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 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, 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 hàm băm params cho tất cả các biến dạng 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. Họ 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.

31
Adam Crossland

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 trên cơ sở dữ liệu hiện có. ActiveRecord của Rails rất quan tâm về cách các bảng nên được cấu trúc (bảng phải có một bảng và chỉ có một cột số nguyên làm khóa chính được gọi là 'id', v.v.) vì vậy nếu các bảng hiện có của bạn không tuân theo tùy chọn ActiveRecord, thật khó để ActiveRecord hoạt động. Nhưng phát triển ứng dụng mới với db mới với ActiveRecord và Rails là 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 thay thế cho Rails ActiveRecord được gọi là DataMapper , nhưng tôi chưa thử.

6
Endy Tjahjono

Tôi chưa bao giờ làm việc với Ruby trên Rails, vì vậy tôi không đủ điều kiện để trả lời câu hỏi này, nhưng có một điều tôi thích về ASP.NET MVC là sự an toàn về kiểu. 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 rằng 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 gõ đúng.

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

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.Site là không gian tên chứa một lớp có tên ContactViewModel, sau đó đối với các khung nhìn của Dao cạo, bạn thực hiện bằng cách đặt một dòng như thế này ở đầu chế độ xem:

@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 tế 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 bằng thuộc tính Model 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.

2
Umar Farooq Khawaja

Đã 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 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ó nhiều hơn "Mở" 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ì rằng không phải 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.

2
Wayne Molina

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 Rails clone trừ Activerecord. Vì vậy, Rails gần như chắc chắn có bộ tính năng lớn hơn nhiều và một hệ sinh thái plugin/gem lớn hơn nhiều.

1
scottschulthess

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 tài sản ở một nơi và tất cả các tham chiếu đến tài sản đượ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à ngôn ngữ được diễn giải;) Bản chất của Ruby, cách 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 tao nhã, hãy xem cuốn sách Eloquent Ruby để biết một số ví dụ. Và rất nhiều Rails khuôn khổ 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, Dependency Injection và IOC container hầu như là các yêu cầu để tạo mã có thể kiểm tra. Điều đó không cần thiết trong Ruby.

Biên tập:

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 ASP.NET không cung cấp bất kỳ hỗ trợ cơ sở dữ liệu nào. Khung .NET 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ể nhận 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, việc hỗ trợ xử lý 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à một khung MVC, chỉ đơn thuần là một 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 đó)

1
Pete