Что ASP.NET MVC может делать, а Ruby on Rails не может? [закрыто]

37

ASP.NET MVC и Rails имеют схожую область использования, построены на одной архитектуре, обе платформы относительно новые и с открытым исходным кодом.

Поэтому, как программист на Rails, я хотел бы знать, что может делать ASP.NET MVC, а Ruby on Rails - и наоборот?

Никита Барсуков
источник
Отличный вопрос Я разработчик MVC, и мне интересно узнать ответ на этот вопрос.
StuperUser
14
Эти типы вопросов являются открытыми и лучше ответить на троллинг в Интернете ИМХО. Что может сделать BMW 335, чего не может Hyundai Sonata? У них обоих есть 4 попытки, руль и они построены на одной и той же структуре потребления; топлива. Эти вопросы всплывают из-за отсутствия исследований по пониманию данных тем, которые могут помочь в более прямом вопросе ... Я уверен, что многие не согласятся, так как это программисты ...
Аарон Макивер
1
@ Аарон - Несмотря на то, что мне пришлось добавить ответ на этот вопрос, я в принципе согласен с вами и надеюсь, что дал понять, что, если брать ваш аналог, мы сравниваем один автомобиль с другим.
Адам Кросслэнд
10
Я лично думал, что это был правильный вопрос. Такие вопросы не следует сбивать с такой готовностью, потому что многие из нас знают только одну сторону истории, и это помогает понять и другую сторону. Кстати, задание вопроса о StackExchange квалифицируется как исследование в моей книге.
Умар Фарук Хаваджа
3
Я часто задаю подобные вопросы и их сбивают, поэтому я хотел бы показать некоторую поддержку здесь для ОП. Решения, принимаемые при кодировании, почти всегда субъективны. Мое право может быть вашей ошибкой, в то время как оба могут разрабатывать рабочие решения с равными (субъективными) достоинствами. В этом случае ФП хочет получить мнение об относительных достоинствах двух противоположных технологий. Вы не найдете эту информацию нигде, кроме как в умах тех, кто прошел через практический процесс выбора одного над другим. Поэтому это законный вопрос.
Ян

Ответы:

31

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

Адам Кроссленд
источник
6
Что касается параметров действия: я бы подумал, что public ActionResult Edit(Foothing foothing), например, функции ModelBinder были еще лучше.
rmac
10
Примеры рельсов довольно устарели. Они работают, но есть лучшие способы сделать это.
Джейсон w
2
@ Джейсон: не могли бы вы остановиться на этом и, возможно, опубликовать суть ?
Дан
3
Я согласен с тем, что request.post? выглядит также необычно для меня (возможно, потому что это использовалось в более старых версиях). Я начал с Rails 3, и метод редактирования всегда «get». Я предполагаю, что вы можете настроить его как пост, но Rails использует шаблон RESTful, который будет использовать метод «update» для выполнения поста с любыми изменениями, которые могут произойти в модели. Таким образом, если все сделано правильно, вам даже не нужно проверять, был ли метод 'edit' постом.
PhillipKregg
3
Голосование за вас просто потому, что вы представляете разумный аргумент. Я предпочитаю Rails, но это совершенно субъективно, и вы хорошо аргументируете свое дело.
Стив Хилл
6

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

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

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

Энди Тяхджоно
источник
9
ActiveRecord в Ruby позволяет исключить много кода, если вы следуете определенным соглашениям, но это не обязательно. Если соглашения не соблюдаются, то вы должны быть более явными.
Кевин Клайн
1
ASP.NET MVC имеет Entity Framework для ORM, который до сих пор был довольно хорош в моем опыте работы с ним.
Купер
Если под «удивительным» вы имеете в виду выполнение плохо сгенерированных запросов в 20 раз медленнее, чем правильно написанный SQL, тогда да;) ... Dapper Contrib - это то, что я нашел великолепным и быстрым ...
niico
2

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

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

Уэйн Молина
источник
9
-1 Я не вижу причин, по которым ASP.NET MVC можно было бы считать более гибким - если вы посмотрите на основные компоненты, маршрутизацию, контроллеры, рендеринг, все они просто сдирают рельсы и также пропускают множество функций.
scottschulthess
1
Как asp.net mvc «более открыт»? Я могу пропустить всю грубую работу с лесами и создать свои модели и контроллеры с нуля, а также создать вложенные ассоциации - один ко многим, много к одному, много ко многим - без каких-либо «поломок». И, если я решу использовать тяжелый интерфейс javascript, я могу с такой же легкостью отправить все свои данные модели клиенту в формате JSON (или XML, или в любом другом формате). Кроме того, если вы можете подумать о функциональности, которую вы хотели бы реализовать, то, вероятно, уже есть жемчужина для этого. Нетрудно найти нетривиальные приложения на Rails.
PhillipKregg
2
Возможность перехода на raw c # / .net framework может считаться более гибкой?
Крис Барри
2
Очень поздно об этом, но то, что я имел в виду в этом посте, - ASP.NET MVC позволяет перейти на C # /. NET и использовать всю инфраструктуру. Rails в то время (около 2.0, я думаю, я не помню) в основном делали CRUD очень простым, а все остальное - сложным; проект, над которым я работал, когда писал, это было сделано в Rails (моя ошибка) и сломался в ту минуту, когда мы выполняли логику, кроме «чтение из базы данных, отображение на странице», если бы я делал это в C # / ASP.NET MVC ( 1.0 на данный момент IIRC) Я бы не столкнулся со многими проблемами, которые я сделал, выбрав вместо этого Rails для приложения.
Уэйн Молина
2

Я никогда не работал с 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 это, но я бы на это надеялся.

Умар Фарук Хаваджа
источник
Язык Ruby также строго типизирован (также типизирован по уткам). А Rails использует активную запись, чтобы автоматически связывать свои модели с ее представлениями. Вам не нужно объявлять их в контроллере. Если вы хотите создать вложенную иерархию представлений, вы должны создать переменную экземпляра в контроллере, представляющую модели, которые вы хотели бы передать в представление. Так что да, они оба могут делать одно и то же.
PhillipKregg
1

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

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

scottschulthess
источник
2
Да, но Rails существует уже около 8 лет, поэтому у него есть преимущество. Я перехожу с Rails на asp.net и MVC 3 на самом деле очень хорош. Entity Framework и менеджер пакетов NuGet были очень впечатляющими для меня.
PhillipKregg
1

По моему ограниченному опыту, главное преимущество 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, если вы идете по этому пути)

Пит
источник
2
Entity Framework 5.0 Code First поддерживает миграцию
hofnarwillie
На самом деле, первые миграции кода поддерживаются начиная с версии 4.1, которая была выпущена AFAIK вскоре после моего редактирования.
Пит
-1

Моя главная проблема с 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]

Майк Бетани
источник
8
Вам не нужно свойство внешнего ключа для объектов вашей сущности. Кроме того, EF - это совершенно отдельный продукт, который никак не интегрирован с ASP.NET MVC. Вы должны использовать модели представления для создания своего пользовательского интерфейса и создания любых выпадающих списков или других элементов управления.
Люцифер Сэм
Я согласен. Вы не должны иметь никаких ключей ID вообще в своих структурах сущностей. ORM должен обрабатывать идентичность объекта. Но точка взята; Я действительно жалуюсь больше на ужасную EF ORM. Этот пример, кстати, является упрощенной версией, поступающей непосредственно от Microsoft. Именно так они это и делают в своем примере с ContosoUniversity. Это говорит о моей точке зрения. Microsoft не знает, как сделать MVC или ORM, и их примеры показывают это.
Майк Бетани
1
Добавление свойства ColorID позволяет реализовать шаблоны отложенной загрузки, которые иногда очень полезны. Например, если ссылочный объект очень большой и вам не нужны все значения свойств объекта, то было бы напрасной тратой времени на обработку всего этого, только чтобы найти связанную с ним часть идентификатора (ColorID) , Это также позволяет вам реализовать внешние ключи Nullable / Non-Nullable, то есть что, если цвет не всегда нужен? Измените ColorID на обнуляемое целое числоint?
hofnarwillie