ASP.NET MVCでできることとRuby on Railsでできないことは何ですか？[閉まっている]

ASP.NET MVCとRailsの使用領域は似ており、同じアーキテクチャを中心に構築されています。どちらのフレームワークも比較的新しく、オープンソースです。

それで、私が知りたいRailsプログラマーとして、ASP.NET MVCができることとRuby on Railsができないこと、そしてその逆のことを知りたいですか？

RailsとASP.NET MVCの両方を使用して実際のアプリケーションを開発しましたが、この答えには重大な注意事項があります：バージョン2以前のRailsで学習し開発したため、私のRailsの知識。

ことで、私はないと思います、と述べた何もなく一方他で行うことができます。Webアプリケーションの一連の要件を考えると、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で非常に一般的なものです。自明ではない場合、Actionコードは大きくて乱雑になる可能性があり、多くの場合、きれいに別のメソッドにリファクタリングできることを望みます。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が行うもう1つの優れた機能（これも私の意見です）は、フォーム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について私が本当に愛していた2つのことです。健全な開発者や有能な開発者が一方のフレームワークをもう一方よりも選択する理由は十分ではありません。

Railsに対するASP.NET MVCの利点の1つは、既存のデータベース上に新しいアプリケーションを構築する必要がある場合です。RailsのActiveRecordはテーブルの構造について非常に考えられています（テーブルには「id」と呼ばれる主キーとして1つの整数列が必要です）、既存のテーブルがActiveRecordの設定に準拠していない場合、ActiveRecordを作成するのは難しいです作業。ただし、ActiveRecordとRailsを使用した新しいdbを使用した新しいアプリの開発は高速です！

ASP.NET MVCにはデフォルトのORMはありません。ニーズに合ったデータアクセス戦略を選択できます。nhibernateのような一部のORMは、レガシーデータベースをサポートできます。guid主キーなどを持つことができます。

DataMapperと呼ばれるRails ActiveRecordの代替がありますが、私は試していません。

両方を使用した、その答えは、IMO、アプリケーションがより行う必要がある場合にはASP.NET MVCはRailsのよりも柔軟であるということであるだけで、データベースからの読み取り/書き込み。私の経験では、Railsは非常に些細なCRUDロジックを超えて、アプリケーションにあらゆる種類の複雑さやロジックを導入するたびに、迅速かつ大幅に故障します。ASP.NET MVCは、できることについてより「オープン」であるため、この制限はありません。

典型的な「Web 2.0」CRUDアプリで他のすべてが同等であるため、他にできることは何もありませんが、ワークフロー、異なるデータソース、または別のアプリケーションなどとやり取りする必要があるより複雑なアプリケーションこれは一般的なCRUD ではありません。ASP.NETはより多くのことを実行でき、Railsほど制限的ではありません。

私はRuby on Railsを使用したことがないため、この質問に答える資格はありませんが、ASP.NET MVCで気に入っていることの1つは、タイプセーフです。これが邪魔です。Adam Crosslandとrmacはコメントで簡単に触れましたが、次のようなコントローラーメソッドでは、各パラメーターが厳密に入力されることを指摘したいと思います。これにより、文字列表現を適切に型指定された変数に変換することを心配する必要がないという点で、Editメソッド内のコードが非常に簡潔になります。

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

このタイプセーフが表示されるもう1つの場所は、ViewsおよびPartial Viewであり、Partial ViewのビューをPlain Old C＃オブジェクトに関連付けることができます。これは、そのビューまたはパーシャルビューのモデルとして機能します。これにより、特に他のビューを含むビューの階層を構築する場合に、作業が非常に簡単になります。

Infinity.ViewModels.Siteがという名前のクラスを含む名前空間である場合ContactViewModel、Razorビューの場合は、ビューの上部に次のような行を配置することでそれを行います。

@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にはほぼ確実にはるかに大きな機能セットと、はるかに大きなプラグイン/ gemエコシステムがあります。

私の限られた経験では、ASP.NET MVCの主な利点は、コンパイルされた言語であることです。これにより、コンパイル時にすでにプログラミングのバグを検出できます。Rubyは、ユニットテスト中に検出することに依存します。

また、コンパイルされているという事実により、1つの場所でプロパティの名前を変更するなど、高度なリファクタリングツールを使用でき、プロパティへのすべての参照が変更されます。これは少なくとも、多くのRails開発者が使用するTextMateでは実行できません。

一方、Ruby on Railsの主な利点は、インタプリタ言語であるということです;）Rubyの性質、メモリ内のオブジェクトの変更方法、またはクラスへのモンキーパッチは、非常に洗練されたソリューションにつながります。いくつかの例については、本Eloquent Rubyをご覧ください。また、Railsフレームワーク自体の大部分は、この機能に基づいています。

任意のオブジェクトの任意のメソッドをいつでも置換できることも、単体テストの作成に大いに役立ちました。.NETでは、依存性注入とIOCコンテナーは、テスト可能なコードを作成するための実質的な要件です。Rubyでは必要ありません。

編集：

それについて考えた後、おそらくRailsのキラー機能はデータベースの移行です。ASP.NET MVCフレームワーク自体は、データベースサポートを提供しません。.NETフレームワークには、Entity FrameworkやLinq to Sqlなどのデータアクセスコンポーネント/ ORMがいくつかあります。ただし、データベース構造を設計するためのツールはありません。

VSのより高価なバージョンの1つにお金を払うと、データベーススキーマを設計できるData Dudeを入手でき、スキーマをデータベースにデプロイするためのいくつかのツールを使用できます。しかし、私が知る限り、アプリケーションの以前のバージョンからの移行処理のサポートは非​​常に限られています。

データベース移行のサポートがないため、ASP.NET MVCは実際にはMVCフレームワークではなく、単にVCフレームワークであると主張する人もいます。

編集（もう一度）：

Visual Studioツールチェーン/ EFの変更により、前回の編集以降、コードベースの移行が導入されました。（ただし、そのパスを下る場合はFluentMigratorもチェックしてください）

MicrosoftのMVC 3とEntity Frameworkでの私の大きな問題は、驚くほど悪い設計原則です。

私が遭遇した最初の問題の1つは、別のクラスをプロパティとして使用し、可能な値のドロップダウンリストを作成しようとしたときでした。

私のポイントを説明するために、次のような2つのモデルクラスがあるとします。

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フィールドを追加しないと、リンクされたクラスのすべての可能なオプションを含むドロップダウンリストを簡単に作成できません。

これは、あるクラスの内部動作を別のクラスに強く結び付けるため、本当にひどい設計です。ThingはColorIDについて何も知らないはずです。Colorクラスは、IDさえ持っていることを公開せずに、独自の同等性チェックを処理する必要があります。

これは101のベストプラクティスですが、Microsoftはコンピュータサイエンスとオブジェクト指向プログラミングの基本原則をまったく知らないようです。[/ rant]