Предложения для миграции от ASP.NET WebForms до ASP.NET MVC?
Другой подход в зависимости от того, как вы меняете div. Если вы используете JQuery для изменения содержимого div с помощью метода html (), вы можете расширить этот метод и вызвать функцию регистрации каждый раз, когда вы помещаете html в div.
(function( $, oldHtmlMethod ){
// Override the core html method in the jQuery object.
$.fn.html = function(){
// Execute the original HTML method using the
// augmented arguments collection.
var results = oldHtmlMethod.apply( this, arguments );
com.invisibility.elements.findAndRegisterElements(this);
return results;
};
})( jQuery, jQuery.fn.html );
Мы просто перехватываем вызывает html (), вызывает функцию регистрации с этим, которая в контексте относится к целевому элементу, получающему новый контент, затем мы передаем вызов исходной функции jquery.html (). Не забудьте вернуть результаты исходного метода html (), потому что JQuery ожидает его для цепочки методов.
Для получения дополнительной информации об переопределении и расширении метода проверьте http: //www.bennadel. com / blog / 2009-Using-Self-Executing-Function-Arguments-To-Override-Core-jQuery-Methods.htm , где я скрещивал функцию закрытия. Также ознакомьтесь с учебником плагинов на сайте JQuery.
4 ответа
Мое мнение - то, что эти две технологии так отличаются что при сильной связи кода в исходных приложениях Веб-формы, которые лучший подход должен запустить путем выбора одного из них и преобразования его путем создания нового ASP.NET приложение MVC и срывания кода на их соответствующие слои. Который поместит Вас на след повторного использования для портирования других приложений.
Ничего себе, я не уверен, что мы говорим миграция здесь больше - различие больше похоже на перезапись!
Как другие также сказали, MVC является совершенно новым способом создать веб-приложения - большая часть Вашего кода презентации не будет нести через.
Однако, если Вы переписываете в MVC, что Вы уже имеете, хороший прототип. Ваша проблема, вероятно, будет состоять в том, что было бы трудно сделать поразрядно - например, MVC использует URL, переименовывающий out-of-the-box, делая соединение назад и вперед довольно грязного.
Другой вопрос состоял бы в том почему? У многих из нас есть большие длинные унаследованные приложения, что мы хотели бы быть в новейших технологиях, но если Ваше приложение уже работает почему переключатель?
Если бы я смотрел на новое приложение прямо сейчас, то MVC был бы очень сильным кандидатом, но нет никакого усиления, достаточно большого к переключению на него поздно в проекте.
WebForms может жить с контроллерами MVC в том же приложении. По умолчанию маршрутизация не направляет запросы на файлы, которые существуют на диске. Таким образом, Вы могли начать переписывать мелкие детали своего сайта за один раз для использования шаблона MVC и остальной части отпуска его использование WebForms.
Какие-либо указатели, подсказки, приемы или глюки для знания?
Ну, я думаю, что Вы - вероятно, небольшие пути далеко от размышления о приемах и глюках :) Поскольку я уверен, что Вы знаете, ASP.NET, MVC не является некоторой новой версией ASP.NET, но полностью другой парадигмой из ASP.NET, Вы не будете мигрировать, Вы будете предпринимать совершенно новую попытку по разработке заменить существующую систему. Таким образом, возможно, можно разбудить участок при определении требований для приложения, но остальные будут, вероятно, восстановленный с нуля.
На основе (очень общих) проблем Вы описали в своей существующей кодовой базе, необходимо полагать, что пользование этой возможностью изучает некоторые текущие лучшие практики в разработке слабо связанных систем. Это легко сделать, потому что современные "лучшие практики" легко понять и легкий практиковать, и существует огромная общественная поддержка и высокое качество, инструменты открытого исходного кода для помощи в процессе.
Мы перемещаем приложение ASP/ASP.NET в ASP.NET MVC в это время также, и это - заключение, мое предварительное исследование привело меня к, так или иначе.
Вот сообщение к ссылкам на использование ASP.NET MVC, но я запустил бы, читая это сообщение. Сообщение о NHibernate (инструмент ORM) на его поверхности, но обсуждение и ссылки о разбирании в основах, и результат подготовки портировать сайт ASP.NET на MVC. Некоторые эталонные архитектуры, связанные с в том сообщении, основаны на ASP.NET MVC. Вот другое сообщение о NHibernate, но в разделе "Best Practices & Reference Applications" больше всего, если не всеми перечисленными эталонными приложениями является ASP.NET приложения MVC также. Эталонные архитектуры могут быть чрезвычайно полезны для того, чтобы быстро получить чувство для того, как оптимальный, удобный в сопровождении ASP.NET сайт MVC мог бы быть разработан.