I want to start migrating a WebForms App to MVC. The process will be gradual, so both systems must co-exist.
The question is: Should I have two MasterPages, one for the WebForms pages and other for the MVC views? Is there a way to have only one?
In ASP.NET MVC the master page should derive from System.Web.Mvc.ViewMasterPage while in classic WebForms from System.Web.UI.MasterPage. If in MVC you use the latter you won't have access to any helpers. Although you could use ViewMasterPage in classic webforms because it derives from MasterPage (once again you won't have access to helpers in the web forms application but who cares).
So to answer your question, yes, you could have a common master page assuming it derives from ViewMasterPage.
This being said you probably won't be able to make this work as in an MVC master page you would use HTML helpers to render partial views like Html.RenderPartial which doesn't make much sense in a classic WebForms application and vice versa in a classic WebForms application you would probably be using some server side controls like <asp:xxx runat="server" /> or have a single form tag (again with runat="server") polluted with ViewState, etc... which hardly makes any sense in MVC. So my recommendation would be not to do like this.
Related
Currently we are migrating an existing asp.net web application to asp.net mvc 2 platform. All of our pages performs some business functionality before loading the page or initializing the page. How to achieve this similar behavior in asp.net mvc
The logic which we have currently in pagebase class for web app like this..
if (!Page.IsPostBack)
// Presenter.PerformStartUp()
Please help.
Thanks
Subu
ASP.NET MVC is a totally different pattern than what you might have been used in classic WebForms. There are no events in MVC. The are no pages in MVC. There is notion of PostBack in MVC. There is no ViewState in MVC. There are no server side controls in MVC.
In MVC you have a Controller which receives the user request, it manipulates the Model and passes a view model to the View for displaying. A good starting point is here: http://asp.net/mvc
If the existing application you are trying to migrate has been written properly and it has a service layer and a data access layer at best you could reuse those parts into the new ASP.NET MVC application.
In asp.net mvc you create ActionResult methods by decorating them with the attribute [HttpPost] and [HttpGet](HttpGet is default) this is what sepparates between a Get and Post.
This might be the most trivial question asked, but I raise it again. Am planning to get started with asp.net MVC on a personal project and here am struck if it supports webparts or any other alternative to it is present. I intend to have a start page similar to igoogle or pageflakes, but my initial research pointed out that as there's no ViewState nor Postback concepts in ASP.NET MVC implementing web parts is not possible.
If that is the case, are there any resources which helps in building a start page as the one i wish to using MVC.
PS: Links I found in the initial research
Quick tips on asp.net MVC -
webparts framework
Building widgets using jquery in
asp.net MVC
You should use AJAX to create widgets that can interact with the server without reloading the page.
This way, the widgets will not affect each-other.
jQuery will be useful here.
Alternatively, you could put each widget in its own <iframe>.
I have been using jqGrid as my grid view to my data for some time now. It works well and it was easy to implement into my solution. However, due to some refactoring going on within the project right now, I have been looking into it again.
The project itself is built around ASP.NET MVC 2 (.NET 4.0). We need some extra functionality such as:
Being able to add columns.
Inline editing of columns.
Sorting
Filter
Paging
Searching
jqGrid does all of this (although, not all of this functionality is implemented yet - some of it is new based on new needs). But, given that I am using ASP.NET MVC, I was wondering if it would make more sense to switch to the Html.Grid helper. It looks just as easy to implement for the things I know it can do (Sorting/Filtering/Paging), but I do not know if it can even do the other tasks (in a fairly straightforward manner) - anything I have found seems somewhat "hackish."
Can anybody enlighten me on A.) the capabilities of Html.Grid to jqGrid and B.) if there is any reason I'd want to take Html.Grid.
I use jqGrid successfully with ASP.NET MVC 2 (.NET 4.0) and have all the features which you describe in your question. Moreover all pages having jqGrid looks like very simple.
I don't use Html.Grid or any MVC controls. I include just pure HTML fragment <table id="list"></table><div id="pager"></div> on the page. Additionally I include the JavaScript which initialize the "list" table and the "pager" div as the jqGrid. So the implementation is independent from MVC concept. The most important part of the jqGrid integrations is the actions which get back pure JSON output and which implement GET/PUT/POST/DELETE operations with the jqGrid. You can read more about the approach here (see also many links with code examples included in the answer).
To be exactly I prefer to use WCF as a part on my ASP.NET MVC solution and the WCF methods provide the data needed for jqGrid (see here more details), but you can implement all as pure ASP.NET MVC actions.
If you use Unit testes for you ASP.NET MVC site you can successfully write tests for WFC methods or controller actions used by jqGrid. In the way you will test the most parts of jqGrid implementation.
After looking at both approach, I decided the jqGrid was a far easier (and simpler) approach for what I was attempting to do.
I'm completely new to C#, asp.net and asp.net mvc. I'm just starting and trying.
so here is my question: what's the difference between ASP.NET MVC Html.helpers and ASP.NET Controls? I know they both can be used to create forms in a page, but what's the difference? I mean, I can use ASP.NET Controls in my MVC project, so what's the point of using Html.helpers? It would be great if somebody explains the difference about Html tags too.
So,when I should use ASP.NET Controlls, when I should use ASP.NET MVC, and when I should use Html Tags?
by the way, I'm using ASP.NET MVC2 in Visual Web Developer 2008 Express.
sorry for my bad English thingy!
Big difference, basically an HTML Helper translates to HTML on the Server when it pushes back to the client.
Controls are not available in MVC (you are thinking web forms), but that's a personal preference whether you like this or not. The forms make it easy to create complicated HTML structures, but there's a lot of "Magic" in how they render, MVC gives you complete control.
Once you start using MVC more you will appreciate the flexibility and not miss controls one bit. Plus, a lot of Open Source stuff out there to give you powerful "Helpers"
To add to Mark's answer: Although both ASP.NET controls and HtmlHelpers emit HTML, that's where the similarities end.
ASP.NET controls are very heavy. Many of them maintain their own state across postbacks to give the illusion that you are programming a stateful Windows Forms application. These controls have strange and mangled ID's, add many bytes to your "viewstate" hidden form field, and often have difficult to control markup and CSS styling.
HtmlHelpers render HTML in a customizable way that is lightweight because you control the HTML that is emitted, ideally WITHOUT any state information littering your markup. You control the ID's, the styles, everything. But you lose the automatic state management that the controls give you.
Good Afternoon,
I'm rebuilding an event ticketing site originally developed using ASP.NET 3.5 WebForms and am considering using ASP.NET MVC2 for the rebuilt solution. I like the idea of friendly URLs as the current site has very long query string URLs for each specified event. MVC2 also appeals from a separation of concerns point of view as well. The biggest unknown for me is will MVC2 handle calls to 3 separate web services (SOAP and REST) to get ticket availability? That is, does the controller functionality permit use of such web services? Finally, MVC3 is due to RTM in January. Am I better off waiting for MVC3, or can I start the project in MVC2 and port it later?
Thanks for all your advice and insight.
MVC can handle any HTTP request as ASP.NET forms does. Indeed you should consider to use WCF for handling SOAP queries. And yes, sure you can easely create REST API with MVC.
It is better to start now, with ASP.NET MVC 3 RC2. It is very stable and nice. This will minimize migration work. Welcome to MVC happy world!
The controller will let you run pretty much any code you want.
I just started using MVC in a big project and it's turning out well. We went with MVC 3 and it's been a little tricky living on the edge, but it seems to have a lot of nice improvements. I'm extremely happy to be using MVC instead of Web Forms. To me, it seems to flow smoothly instead of fighting with the way the web works.