Asp.Net Монорельс MVC vs Castle
-
08-07-2019 - |
Вопрос
У меня есть некоторый опыт сборки приложений с помощью Asp.Net, но сейчас фреймворки MVC становятся все более популярными.Я хотел бы попробовать создать новое многоязычное веб-приложение, используя with Asp.Net MVC или Castle MonoRail, но я не знаю, какой из них подходит для меня.Мне не нравится механизм просмотра веб-форм, но мне нравится функция маршрутизации в Asp.Net MVC.
- Может ли кто-нибудь рассказать о плюсах и минусах между ними?
- Какой ViewEngine также лучше подходит для переопределения главного шаблона?
Решение
Выступая в качестве адвоката монорельса, я должен сказать вам, вероятно, следует пойти на ASP.NET в MVC.Честно говоря, простой факт, что ASP.NET MVC собирается стать архитектурой по умолчанию в течение трех лет, вероятно, должен повлиять на это.Год назад это уравнение было иным просто потому, что архитектура по умолчанию имела серьезные проблемы с производительностью по сравнению с монорельсовой дорогой.
Если вы хотите поговорить о технических преимуществах и недостатках:
- ASP.NET AJAX - это беспорядок (избегайте его), но теперь у них есть jQuery.На самом деле, поддержка jQuery лучше, чем в любой другой среде.Конечно, вы полностью получите это только при интеграции IDE со стандартным механизмом просмотра.
- Есть некоторые эстетические улучшения (например, способ передачи информации о модели намного чище и нагляднее, чем монорельсовая дорога).
Кроме того, не сбрасывайте со счетов стандартный движок просмотра.Вам не нужно добавлять в него элементы управления, как вы делали с ASP.NET вы можете закодировать его довольно похожим образом на Brail, только используя C # вместо Boo.
Есть вещи, которые просто уродливы * количество методов, которые принимают object в качестве параметра.Удачи в поиске документации о том, чего именно они ожидают.* Пристрастие Microsoft к абстрактным классам вместо интерфейсов.У них есть свои причины, но мне все равно это не нравится.
Кроме того, во многих отношениях монорельсовая дорога остается более совершенной платформой.Например, в ASP.NET нет абстракции для проверки или подкачки страниц.Кроме того, на самом деле нет никакой помощи для привязки к модели.Помощники обладают очень небольшой функциональностью по сравнению с их монорельсовыми аналогами.
В целом, однако, я думаю ASP.NET MVC - победитель.
Другие советы
Монорельс и ASP.NET MVC в основе своей очень похожи, вам должно быть удобно использовать любой из них.Монорельс существует гораздо дольше и, следовательно, обладает более высокоуровневыми характеристиками.
Основная сила ASP.NET MVC - это механизм маршрутизации, честно говоря, MonoRail имеет в значительной степени эквивалентный механизм маршрутизации, и с некоторой модификацией вы можете использовать ASP.NET Механизм маршрутизации MVC с монорельсовой дорогой в качестве механизма маршрутизации на самом деле находится не в ASP.NET MVC, а в System.Web.Routing (выпущен в .NET 3.5 SP1).ASP.NET MVC и интеграция с Visual Studio также являются плюсом и, вероятно, будут улучшаться по мере приближения к RTM версии v1.
Проект MvcContrib содержит несколько отличных движков просмотра, таких как Spark, NHaml и Brail.Никого нельзя считать "Лучшим", личный фаворит - Spark.Подробнее о spark: http://dev.dejardin.org/documentation/syntax
Движок WebForms имеет intellisense, что является большим преимуществом, которого, насколько мне известно, нет у всех альтернативных движков просмотра.
Помимо предполагаемой популярности и поддержки со стороны Microsoft, ASP.NET В MVC по-прежнему отсутствуют некоторые основные функции, которыми долгое время обладала Монорельсовая дорога, такие как организация контроллеров (Areas), собственные компоненты просмотра и фильтры, которые могут использовать IoC для определения наиболее важных из них.
У меня есть несколько больших приложений, которые используют все эти функции, и мне было нелегко перенести их на ASP.NET MVC.
Я работаю с Monorail уже несколько лет, и хотя MVC выглядит многообещающе, а его гибкость потрясающая, я все еще нахожу странным, что для любой другой вещи, которую я пытаюсь сделать, оказывается, что ее там нет, и мне приходится либо подключать небольшой фрагмент MvcContrib, либо другой фрагмент SharpArchitecture, создавать его самому, вы получаете картину.С монорельсовой дорогой намного проще работать (то есть прямо сейчас).
Я ожидаю, что в ближайшие несколько месяцев ситуация улучшится, поскольку некоторые предлагаемые решения начнут противопоставляться другим и станут более распространенными.Эй, разнообразие вариантов - это хорошо, но поверьте мне, вы же не хотите оказаться в стране Java 3 года назад, где было так много веб-фреймворков, что вы могли создавать свой сайт, используя один для каждой отдельной страницы!
Тем временем я буду продолжать медленно переносить свои MR-приложения на MVC, на всякий случай.
Я думаю, что MVC выигрывает без раздумий.Его набор функций очень похож, но будет более "популярным" из двух (и, следовательно, обычно более широко поддерживается, документируется и распространяется по всему сообществу разработчиков).Кроме того, появился новый ViewEngine (Razor)..и для меня важны улучшения IDE, которые, на мой взгляд, повышают ценность выбора MVC вместо монорельсовой дороги.
Я использовал практически все распространенные ViewEngines, но в итоге запустил свой собственный (создал проект с открытым исходным кодом для этого) с использованием потрясающего движка шаблонов StringTemplate.ST - это истинное разделение проблем, ИМО.В результате я обнаружил, что пишу лучшие приложения с ГОРАЗДО меньшим количеством тегов.Я также выбросил краткое введение и справочное руководство если вы решите пнуть шины на двигателе.Мне потрясающе везло в проектах, которые я уже развернул с его помощью.При этом Razor (MVC 3) выглядит довольно впечатляюще.