ASP.NET MVC는 무엇을 할 수 있고 Ruby on Rails는 할 수 없습니까? [닫은]

ASP.NET MVC와 Rails는 비슷한 사용 영역을 가지고 있으며 동일한 아키텍처를 기반으로 구축되었으며 두 프레임 워크는 비교적 새롭고 오픈 소스입니다.

그래서 Rails 프로그래머로서 ASP.NET MVC가 할 수있는 것과 Ruby on Rails가 할 수없는 것과 비자가 무엇인지 알고 싶습니다.

Rails와 ASP.NET MVC를 모두 사용하여 실제 응용 프로그램을 개발했지만이 답변에는 상당한 경고가 있습니다. 버전 2 Rails를 통해 배우고 개발했기 때문에 완전히 최신 버전이 아닐 수 있습니다. 레일스 지식.

즉, 하나는 할 수 있지만 다른 것은 할 수 없는 것이 있다고 생각하지 않습니다 . 웹 응용 프로그램에 대한 요구 사항이 주어지면 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모든 폼 변수에 대한 해시 를 쿼리해야 합니다. 'status', '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를 사용하면 모든 폼 값을 매개 변수로 Action 메서드에 깔끔하게 가져올 수 있습니다.

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

이것이 제가 ASP.NET MVC 또는 Rails에 대해 정말 좋아했던 두 가지입니다. 제정신이거나 유능한 개발자가 다른 프레임 워크 중 하나를 선택해야하는 이유는 충분하지 않습니다.

Rails를 통한 ASP.NET MVC의 한 가지 장점은 기존 데이터베이스를 통해 새 응용 프로그램을 빌드해야하는 경우입니다. Rails의 ActiveRecord는 테이블이 어떻게 구성되어야하는지에 대해 매우 의견이 많으며 (테이블에는 'id'라고하는 기본 키로 하나의 정수 열만 있어야 함) 기존 테이블이 ActiveRecord 환경 설정을 준수하지 않으면 ActiveRecord를 만들기가 어렵습니다. 작업. 그러나 ActiveRecord 및 Rails를 사용하여 새로운 db로 새로운 앱을 개발하는 것은 빠릅니다!

ASP.NET MVC에는 기본 ORM이 없습니다. 필요에 맞는 데이터 액세스 전략을 선택할 수 있습니다. nhibernate와 같은 일부 ORM은 레거시 데이터베이스를 지원할 수 있습니다. guid 기본 키 등을 가질 수 있습니다.

DataMapper 라는 Rails ActiveRecord의 대안이 있지만 시도하지 않았습니다.

둘 다 사용하는 데, 그 대답은 IMO 응용 프로그램 요구 사항이보다 더 할 경우 ASP.NET MVC는 레일보다 더 유연하다는 것이다 단지 데이터베이스에서 읽기 / 쓰기. 내 경험상 Rails는 아주 간단한 CRUD 논리를 넘어서 어떤 종류의 복잡성이나 논리도 응용 프로그램에 도입 할 때 신속하고 무겁게 분해됩니다. ASP.NET MVC는 수행 할 수있는 작업에 대해 더 "개방적"이므로이 제한이 없습니다.

일반적인 "Web 2.0"CRUD 앱에서 다른 모든 것들은 다른 것보다 할 수있는 것이 아니라 워크 플로가 필요하거나 데이터 소스가 서로 다르거 나 다른 애플리케이션 또는 다른 것과 상호 작용할 수있는 더 복잡한 애플리케이션을위한 것입니다. 이 아닌 일반적인 CRUD는, ASP.NET은 더 많은 작업을 수행하지 레일 제한적으로 할 수있다.

나는 Ruby on Rails와 함께 일한 적이 없으므로이 질문에 대답 할 수있는 자격이 없지만 ASP.NET MVC에 대해 내가 좋아하는 것은 형식 안전성입니다. 이것은 방해가됩니다. Adam Crossland와 rmac은 그들의 의견에 간단히 언급했지만 다음과 같은 컨트롤러 방법을 사용하면 각 매개 변수가 강력하게 입력됩니다. 이렇게하면 문자열 표현을 올바르게 입력 된 변수로 변환 할 필요가 없으므로 Edit 메서드 내의 코드가 훨씬 깔끔해집니다.

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

이 형식 안전성이 표시되는 다른 위치는 뷰 및 부분 뷰에서 부분 뷰의 뷰를 Plain Old C # 객체와 연결할 수 있으며 뷰 또는 부분 뷰의 모델로 사용됩니다. 이것은 특히 다른 뷰를 포함하는 뷰의 계층 구조를 구축하려는 경우 인생을 훨씬 쉽게 만듭니다.

Infinity.ViewModels.Site이라는 클래스가 포함 된 네임 스페이스 인 경우 ContactViewModelRazor 뷰의 경우 뷰의 맨 위에 다음과 같은 행을 배치하여 수행합니다.

@model Infinity.ViewModels.Site.ContactViewModel

ASPX 뷰의 경우 다음과 같이 뷰를 선언하여 수행합니다.

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

모델 조치의 실제 인스턴스를 Controller 조치 메소드의보기와 연관시킨 후보기의 Model특성으로 보기에서 모델 오브젝트의 인스턴스에 액세스하십시오 .

나에게있어이 강력한 유형은 매우 시원합니다. ASP.NET MVC를 만든 팀은 3 가지 모델, 뷰 및 컨트롤러 영역을 각각 강력하게 입력하기 위해 많은 노력을 기울였습니다.

Ruby-on-Rails에 이것이 있는지 확실하지 않지만, 희망합니다.

그것들은 매우 유사하며, 대부분 "같은 일을"할 수 있습니다. 어떤 것들은 다른 것보다 쉽고 어렵습니다.

원래 릴리스에서 ASP.NET MVC를 사용했으며 분명히 Rails 클론에서 activerecord를 뺀 것입니다. 따라서 Rails는 훨씬 더 큰 기능 세트와 훨씬 더 큰 플러그인 / 젬 에코 시스템을 가지고 있습니다.

제한된 경험에서 ASP.NET MVC의 주요 이점은 컴파일 된 언어라는 것입니다. 이를 통해 컴파일시 이미 일부 프로그래밍 버그를 감지 할 수 있습니다. 여기서 Ruby는 단위 테스트 중에 감지해야합니다.

또한 컴파일 된 사실 덕분에 한 곳에서 속성 이름을 변경하는 등 고급 리팩토링 도구를 사용할 수 있으며 속성에 대한 모든 참조가 변경됩니다. 많은 Rails 개발자들이 사용하는 TextMate에서는이 작업을 수행 할 수 없습니다.

다른 한편으로, Ruby on Rails의 주요 장점은 해석 된 언어라는 것입니다.;) 메모리의 객체를 수정하거나 클래스를 원숭이 패치하는 방법 인 Ruby의 특성은 매우 우아한 솔루션으로 이어질 수 있습니다. Eloquent Ruby 서적 에서 몇 가지 예를 확인하십시오. 그리고 많은 Rails 프레임 워크 자체가이 능력을 기반으로합니다.

언제든지 어떤 객체에서든 메소드를 대체 할 수있는 기능을 통해 단위 테스트 작성에 크게 도움이되었습니다. .NET에서 Dependency Injection 및 IOC 컨테이너는 테스트 가능한 코드를 만들기위한 사실상 요구 사항입니다. 루비에서는 필요하지 않습니다.

편집하다:

이를 고려한 후 아마도 Rails의 가장 큰 특징은 데이터베이스 마이그레이션 일 것입니다. ASP.NET MVC 프레임 워크 자체는 데이터베이스 지원을 제공하지 않습니다. .NET 프레임 워크에는 Entity Framework 및 Linq to Sql과 같은 일부 데이터 액세스 구성 요소 / ORM이 있습니다. 그러나 데이터베이스 구조를 설계하기위한 도구는 없습니다.

더 비싼 VS 버전 중 하나를 지불 하면 데이터베이스 스키마를 디자인하고 스키마를 데이터베이스에 배포하기위한 도구를 가질 수있는 Data Dude를 얻을 수 있습니다. 그러나 내가 알 수있는 한, 이전 버전의 응용 프로그램에서 마이그레이션을 처리하는 데 대한 지원은 매우 제한적입니다.

일부 사람들은 ASP.NET MVC가 데이터베이스 마이그레이션에 대한 지원 부족으로 인해 실제로 MVC 프레임 워크가 아니라 VC 프레임 워크라고 주장합니다.

편집 (다시) :

Visual Studio 툴체인 / EF를 변경하면 마지막 편집 이후 코드 기반 마이그레이션이 도입되었습니다. (그러나 해당 경로를 따라가는 경우 FluentMigrator를 확인하십시오)

Microsoft MVC 3 및 ​​Entity Framework의 주요 문제점은 엄청나게 나쁜 디자인 원칙입니다.

내가 처음 만난 문제 중 하나는 다른 클래스를 속성으로 사용하고 가능한 값에 대한 드롭 다운 목록을 만들려고 할 때였습니다.

내 요점을 설명하기 위해 다음과 같은 두 가지 모델 클래스가 있다고 가정하십시오.

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 속성을 생성하면 실제 ORM에는 충분하지만 EF에는 충분하지 않습니다. Thing 클래스에서 Color 속성에 대한 중복 ID를 다음과 같이 추가해야합니다.

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도 노출시키지 않고 자체 동등 검사를 처리해야합니다.

이것은 모범 사례이지만, Microsoft는 컴퓨터 과학 및 객체 지향 프로그래밍의 기본 원칙을 완전히 인식하지 못하고 있습니다. [/ rant]