Что 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. В нетривиальных случаях код 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 делает это очень круто (опять же на мой взгляд), также связана с обработкой формы 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. Они не являются достаточной причиной для того, чтобы любой здравомыслящий или компетентный разработчик выбрал одну платформу вместо другой.

Одним из преимуществ ASP.NET MVC над Rails является необходимость создания нового приложения поверх существующей базы данных. ActiveRecord от Rails очень самоуверен относительно того, как таблицы должны быть структурированы (таблица должна иметь один и только один целочисленный столбец в качестве первичного ключа с именем 'id' и т. Д.), Поэтому, если ваши существующие таблицы не соответствуют предпочтениям ActiveRecord, сложно сделать ActiveRecord Работа. Но разработка нового приложения с новой базой данных с ActiveRecord и Rails - это быстро!

ASP.NET MVC не имеет ORM по умолчанию. Вы можете выбрать стратегию доступа к данным, которая соответствует вашим потребностям. Некоторые ORM, такие как nhibernate, могут поддерживать устаревшие базы данных. Вы можете иметь основной ключ guid и т. Д.

Существует альтернатива Rails ActiveRecord, называемая DataMapper , но я не пробовал.

При использовании обоих вариантов ответ IMO заключается в том, что ASP.NET MVC более гибок, чем Rails, если вашему приложению нужно делать больше, чем просто чтение / запись из базы данных. По моему опыту, Rails ломается быстро и тяжело, как только вы привносите в приложение любую сложность или логику, помимо очень тривиальной логики CRUD. ASP.NET MVC не сталкивается с этим ограничением, поскольку он более «открыт» в отношении того, что вы можете сделать.

При прочих равных условиях в типичном приложении CRUD для Web 2.0 нет ничего, что можно сделать поверх другого, но для более сложного приложения, которому необходим рабочий процесс, или разрозненные источники данных, или для взаимодействия с другим приложением, или чем-то еще это не типичный CRUD, ASP.NET может сделать намного больше и не быть таким ограничительным, как Rails.

Я никогда не работал с Ruby on Rails, поэтому я не совсем квалифицирован, чтобы отвечать на этот вопрос, но одна вещь, которая мне нравится в ASP.NET MVC, - это безопасность типов. Это приходит в пути. Адам Кроссленд и rmac кратко коснулись этого в своих комментариях, но я хотел бы отметить, что при использовании метода контроллера, подобного следующему, каждый из параметров будет строго типизирован. Это делает код в методе Edit намного чище, так как вам не нужно беспокоиться о преобразовании строковых представлений в правильно типизированные переменные.

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

Другое место, которое проявляет безопасность типов, находится в представлениях и частичном представлении, где можно связать представление частичного представления с обычным старым 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 областей Model, View и Controller была строго типизирована.

Я не уверен, есть ли у Ruby-on-Rails это, но я бы на это надеялся.

Они очень похожи, и все они в основном могут «делать одно и то же», просто некоторые вещи легче в одном и сложнее, чем в другом.

Я использовал ASP.NET MVC вокруг оригинальной версии, и это был определенно клон Rails минус activerecord. Итак, Rails почти наверняка имеет гораздо больший набор функций и гораздо большую экосистему плагинов / гемов.

По моему ограниченному опыту, главное преимущество ASP.NET MVC в том, что это скомпилированный язык. Это позволяет вам обнаруживать некоторые программные ошибки уже во время компиляции, когда Ruby полагается на их обнаружение во время модульного тестирования.

Кроме того, тот факт, что он скомпилирован, позволяет использовать расширенные инструменты рефакторинга, например, изменять имя свойства в одном месте, и все ссылки на свойство изменяются. По крайней мере, этого нельзя сделать в TextMate, который используют многие разработчики Rails.

С другой стороны, основным преимуществом Ruby on Rails является то, что он является интерпретируемым языком;) Природа Ruby, то, как вы можете модифицировать любой объект в памяти или обезьяна, исправляет класс, может привести к некоторым очень элегантным решениям; проверьте книгу Eloquent Ruby для некоторых примеров. И большая часть самой платформы Rails основана на этой способности.

Возможность замены любого метода на любом объекте в любое время также очень помогла мне в написании юнит-тестов. В .NET контейнеры Dependency Injection и IOC фактически являются требованиями для создания тестируемого кода. Это не обязательно в Ruby.

Редактировать:

Подумав об этом, вероятно, главной особенностью Rails является миграция базы данных. Платформа ASP.NET MVC сама по себе не обеспечивает поддержку базы данных. .NET Framework имеет некоторые компоненты доступа к данным / ORM, например Entity Framework и Linq to Sql. Но у него нет никаких инструментов для проектирования структуры базы данных.

Если вы платите за одну из более дорогих версий 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. Вы должны добавить избыточный идентификатор для свойства 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; }
}

Если вы не добавите избыточное поле идентификатора для ссылки на сторонний объект, вы не сможете легко создать раскрывающиеся списки со всеми возможными опциями из связанного класса.

Это действительно ужасный дизайн, поскольку он сильно связывает внутреннюю работу одного класса с другим. Вещи не должны ничего знать о ColorID, класс Color должен обрабатывать свои собственные проверки на равенство, не показывая, что у него даже есть ID.

Это лучшие практики, но, очевидно, Microsoft совершенно не знает об основных принципах информатики и объектно-ориентированного программирования. [/ Rant]