Що 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хеш для всіх моїх змінних форм. Скажімо, у мене є форма з полями "статус", "гонкульований", "інвертувати" та "диспозиція":

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 є те, що вам потрібно створити нову програму над наявною базою даних. Rails 'ActiveRecord дуже впевнений у тому, як слід структурувати таблиці (таблиця повинна мати один і лише один цілий стовпець у якості основного ключа, який називається' id 'тощо), тому якщо ваші існуючі таблиці не відповідають налаштуванням ActiveRecord, складно зробити ActiveRecord робота. Але розробка нового додатка з новим db з ActiveRecord та Rails швидко!

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

Є альтернатива Rails ActiveRecord під назвою DataMapper , але я не пробував цього.

Використовуючи обидва, відповідь IMO полягає в тому, що ASP.NET MVC є більш гнучким, ніж Rails, якщо вашій програмі потрібно зробити більше, ніж просто читати / писати з бази даних. На моєму досвіді Rails виходить з ладу швидко і сильно в ту хвилину, коли ви впроваджуєте будь-який складність або логіку в додаток, що перевищує дуже тривіальну логіку CRUD. ASP.NET MVC не стикається з цим обмеженням, оскільки він більше "відкритий" щодо того, що можна зробити.

За інших рівних даних у типовому додатку CRUD "Веб 2.0" немає нічого, що можна зробити над іншим, але для більш складного додатка, який потребує робочого процесу, або розрізнених джерел даних, або для взаємодії з іншим додатком, або будь-чим іншим що це не типовий CRUD, ASP.NET може зробити набагато більше і не бути настільки ж обмежувальними Rails.

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

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

Інше місце, на яке відображається цей тип безпеки, - це View and Partial View, де ви можете пов'язувати вигляд часткового виду з звичайним старим об'єктом 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 майже напевно має набагато більший набір функцій та значно більшу екосистему плагінів / дорогоцінних каменів.

За моїм обмеженим досвідом, головна перевага ASP.NET MVC полягає в тому, що це мова, що складений. Це дозволяє виявити деякі помилки програмування вже при компіляції, де Рубі доводиться розраховувати на виявлення тоді під час тестування одиниць.

Також той факт, що він складений, дозволяє мати вдосконалені інструменти рефакторингу, наприклад, змінити назву властивості в одному місці, і всі посилання на властивість змінюються. Принаймні цього не можна зробити в TextMate, який використовують багато розробників Rails.

З іншого боку, головна перевага Ruby on Rails полягає в тому, що це інтерпретована мова;) Характер Ruby, як ви можете змінити будь-який об’єкт у пам'яті або мавпа-патч класу, може призвести до деяких дуже елегантних рішень; ознайомтеся з книгою Красномовна Рубі на кілька прикладів. І на цій здатності базується багато самих рамок Rails.

Можливість замінити будь-який метод на будь-який об'єкт у будь-який час також мені дуже допомогла в написанні одиничних тестів. У .NET, Dependency Injection та IOC-контейнери практично є вимогами до створення тестового коду. Це не потрібно в Рубі.

Редагувати:

Після роздумів над цим, ймовірно, вбивчою особливістю Rails є міграція бази даних. Рамка ASP.NET MVC сама по собі не забезпечує жодної підтримки бази даних. Рамка .NET має деякі компоненти доступу до даних / 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 повинен обробляти власні перевірки рівності, не виявляючи, що він навіть має ідентифікатор.

Це найкращі практики 101, але, очевидно, Microsoft абсолютно не знає основних принципів інформатики та об'єктно-орієнтованого програмування. [/ Rant]