ASP.Net MVC vs ASP.Net Forms - asp.net

Why would you consider using ASP.Net MVC or standard ASP.Net with forms and controls for a web project? Apart from personal preference what would be the reasons? What sort of projects do you find more suitable for MVC and what projects for normal ASP.Net?
Would you consider transferring your current projects to one or another?

ASP.NET Web Forms and MVC are two web frameworks developed by Microsoft - they are both good choices. Neither of the web frameworks are to be replaced by the other nor are there plans to have them 'merged' into a single framework. Continued support and development are done in parallel by Microsoft and neither will be 'going away'.
Each of these web frameworks offers advantages/disadvantages - some of which need to be considered when developing a web application. A web application can be developed using either technology - it might make development for a particular application easier selecting one technology versus the other and vice versa.
ASP.NET Web Forms:
Development supports state
• Gives the illusion that a web application is aware of what the user has been doing, similar to Windows applications. I.e. Makes 'wizard' functionality a little bit easier to implement. Web forms does a great job at hiding a lot of that complexity from the developer.
Rapid Application Development (RAD)
• The ability to just 'jump in' and start delivering web forms. This is disputed by some of the MVC community, but pushed by Microsoft. In the end, it comes down to the level of expertise of the developer and what they are comfortable with. The web forms model probably has less of a learning curve to less experienced developers.
Larger control toolbox
• ASP.NET Web Forms offers a much greater and more robust toolbox (web controls) whereas MVC offers a more primitive control set relying more on rich client-side controls via jQuery (Javascript).
Mature
• It's been around since 2002 and there is an abundance of information with regards to questions, problems, etc. Offers more third-party control - need to consider your existing toolkits.
ASP.NET MVC:
Separation of concerns (SoC)
• From a technical standpoint, the organization of code within MVC is very clean, organized and granular, making it easier (hopefully) for a web application to scale in terms of functionality. Promotes great design from a development standpoint.
Easier integration with client side tools (rich user interface tools)
• More than ever, web applications are increasingly becoming as rich as the applications you see on your desktops. With MVC, it gives you the ability to integrate with such toolkits (such as jQuery) with greater ease and more seamless than in Web Forms.
Search Engine Optimization (SEO) Friendly / Stateless
• URL's are more friendly to search engines (i.e. mywebapplication.com/users/ 1 - retrieve user with an ID of 1 vs mywebapplication/users/getuser.aspx (id passed in session)). Similarly, since MVC is stateless, this removes the headache of users who spawn multiple web browsers from the same window (session collisions). Along those same lines, MVC adheres to the stateless web protocol rather than 'battling' against it.
Works well with developers who need high degree of control
• ASP.NET web forms automatically generates much of the raw HTML you see when an page is rendered. This can cause headaches for developers. With MVC, you have complete control over what is rendered and there are no surprises. Even more important, is that the HTML forms typically are much smaller than the Web forms which can equate to a performance boost - something to seriously consider.
Test Driven Development (TDD)
• With MVC, you can more easily create tests for the web side of things. An additional layer of testing will provide yet another layer of defense against unexpected behavior.
Authentication, authorization, configuration, compilation and deployment are all features that are shared between the two web frameworks.

WebForms is an abstraction which hides the mechanics of the web from the developer. It allows desktop developers to relatively easily transfer their skills to the web. Whilst it does achieve this in part, in practical scenarios it is usually not long before the abstraction breaks and one has to put in messy workarounds. Unit testing is difficult, because the logic for handling user interactions is tightly coupled with the UI. The HTML produced by a typical WebForms app is far from optimal. It is typically bloated, difficult to read and contains a lot of content which is present only to allow the abstraction to work, e.g. viewstate, which is a huge blob of information to help the abstraction give the illusion of state to the developer, even though the web is a stateless medium.
MVC, however, embraces the mechanics of the web. The fundamental operations which take place in a web request and response are presented to the developer as simple abstractions. MVC has a clear separation of concerns. The model simply represents the business objects or entities with which the system is concerned, with methods for retrieving and storing instances of these objects. The controller take a web request, performs operations against the model, and then hands the model to the view. The view is purely a renderer, for presenting the model to the user and exposing interface items which allow the user to formulate the next request to pass to a controller. This separation of concerns allows for relatively easy unit testing. The developer has complete control over the HTML produced and there is no need for other artifacts to be present (e.g. viewstate).
I prefer MVC. For rare occasions it may be useful to use Webforms, e.g. a quick prototype or demo, but otherwise I would always recommend the use of MVC.
As for transferring a project from Webforms to MVC, this is obviously very subjective and dependent on the application itself, and budgetary constraints, but in general I believe this is a step in the right direction.

You can find many differences, advantages about the ASP.Net MVC over the normal ASP.Net
Applications. if not kindly visit stack overlow page.
Biggest advantage to using ASP.Net MVC vs web forms
the reason for choosing the MVC concept for your application vary on many things
What for your application for ? either kind of forum, reporting tool or intranet website
Whether you want to follow desing pattern or not?
if yes, then whether is that going to be MVC or any other ??
Whether you need modularity for future enhancements?
Whether you need full control on your code?
Better support on the testing part from the developer perspective should be there or not?
If are sure about those things, then you can move ur appln to MVC framework model.
Other wise its better to continue with ASP.Net Web.apps, because it includes all the latest
features what the current industry needs.

Related

Confusion on using asp.net or mvc

Ive been confused about ASP.NET MVC.
As some said, MVC is better than ASP.NET. As some said, they are completely the same thing.
And my colleges debate that MVC is just an extension of asp.net, where asp.net is already in the form of MVC.
In fact I am starting web developing from scratch. If someone might help to clear the fog front of me, it would help a lot.
All ASP.NET web frameworks are build on top of Microsoft ASP.NET Framework. The unique feature of Web API is that it can be used with both MVC and WebForms applications to provide truly restful HTTP services.
Regarding the choice of suitable Asp.NET framework: you may get more information from official source - www.asp.net.
General rule of thumb is the architectural design how you want to build your application.
ASP.NET MVC promotes a cleaner separation which makes the developer think more in depth about design and code separation than traditional web forms.
There are endless debates about what is better but true benefits of ASP.NET MVC as
testability
more control over the rendered HTML
separation of concerns. However with MVC there is much more to learn for the developer.
ASP.NET WebForms - will always be around because some see it as a rapid application development tool. Just drag and drop and let ASP.NET handle the posting, state etc
ASP.NET Web API - is a framework that makes it easy to build HTTP services that reach a broad range of clients, including browsers and mobile devices. ASP.NET Web API is an ideal platform for building RESTful applications on the .NET Framework.
All in all, each of them has certain business solutions to be considered as required.
References to look for comparison:
ASP.NET MVC vs WebForms: speed and architecture comparison
ASP.NET Roadmap: One ASP.NET – Web Forms, MVC, Web API, and more
ASP.NET is the name of the overall web framework. There are a few different technologies that are built on ASP.NET. Two popular examples of these technologies are WebForms and MVC.
WebForms promotes a programming model that looks a lot more like Windows Forms. It attempts to abstract away the stateless nature of the web, and encourages you to use server-side controls instead of HTML. Because WebForms was the primary way to write web applications on ASP.NET for a long time before MVC came out, you'll often see people talk about "ASP.NET" as the same thing as WebForms. This is part of the reason for your confusion. ASP.NET WebForms is very different from ASP.NET MVC, but they are both built on ASP.NET.
ASP.NET MVC gets away from server-side controls. It eliminates the abstractions, allowing you to have closer control over the actual HTML that gets generated. For developers of modern applications, this is very useful because it makes it much easier to use AJAX and rich client-side javascript.
(Humble Opinion incoming)
ASP.NET (in terms of using Webforms) is programming the web for a WinForms developer. You "bind" events, you have "controls" and everything (sessionstate) is stored in a huge hidden field within the page so it knows where it left off from the previous call. You rely heavily on this information being present which is why everything you do needs to reside in that master form wrapping the entire page.
On the other hand, MVC is bringing C# .NET programming back to the web the way the web was intended. No bloat, no hidden fields, no heavy bindings. It's brings everything back to the classic "i have this form and now I need to process it". Arguably, the real magic is the routing methods and the "automatic binding" of submitted fields to an object. (if fields x, y & z are submitted and your action is looking for FooBar with the properties x, y & z it's automatically converted for you.
ASP.NET is common to both WEB-API and ASP.NET MVC. I assume you wonder about MVC or WEB-API.
MVC is a controller / model based with Views. Although the controllers can be used for AJAX json purposes. MVC is a good way to build a serious Browser based Application. The WEB-API allows you to build simple http server features, not necessarily Browser related. Good for REST style programming. Very flexible and a good alternative to WCF services. The are good tutorials on Both on the official ASP.NET site. START here http://www.asp.net/get-started
choose depends on your project n you. I suggest you to choose MVC because its productivity is very high we r using it since 1 year and found better than webforms.
for more knowledge please visit http://www.asp.net/mvc
The choice depends completely on you, I have been developing MVC application since 2010, its going to be over 2 years now have worked with almost all the versions of MVC both with Razor and aspx view. I have also worked on ASP.Net webform based applications.
With MVC you will not get built in controls, you will have to develop every control you want to use, you will have to rely mostly on html controls, while with web forms you will get advantage of using built in controls, Even getting help from other developers in your surroundings may be easy for webforms as you can easily get a webform developer.
But on the other hand with MVC the maintability is very high. As for as productivity is concerned, its very high once your are accustomed to it, initially it will be low as you will be in learning phase. Don't forget to use Entity Framework.
You may also consider developing your App using WebAPI, if it suits your scenario.

Guidance on migrating a .NET windows forms application to a web application

Are there any good books or websites on this subject covering subjects like:
different migration scenario's (big bang, module for module, function for function) pros and cons
do's en dont's
tooling
handling customer expectations
We have a rather large winforms based product which we would like to migrate to the web. Migrating in a 'big bang' scenario would probably take at least two years. We're looking for alternative scenario's.
I'm especially looking for ways to handle the inbetween scenario, what options do you have to keep customers happy.
Let them use the windows application at the same time as the new web
application?
Let the windows application use the new features from the web
application via a service interface?
Accept the cost of double maitenance for a while to keep customers happy?
You are more likely be doing a complete rewrite. Because web is conceptually different from windows forms, there would be a lot of changes.
Your best bet is stop new development on windows forms app. Start writing a new app for the new features. Then start moving one isolated feature at a time to web.
You have two options for the UI
webforms - matches closely with windows forms model. If you are
using any 3rd party controls like devexpress, you can find the
equivalents in webforms.
mvc - It is more like re-architecting the whole presentation layer.
If your UI layer is already separated from business layer, then it
would be a good choice to go down the path of MVC. However the
development experience is totally different from doing windows
forms.
State
Maintaining application state is comparatively simple in windows
forms. In webforms you have viewstate to do that for you. But you are going to run in to rude shocks as you run into limitations of viewstate, especially when it gets too large.
In MVC, you are completely responsible for maintaining the state.
New skills
You require new skills to mimic state-full scenarios
Strong understanding of javascript, ajax, at least one javascript
framework like jquery. 3rd party commercial tool kits can ease some
of these pains.
Depending on complexity you might need web application frameworks
like Backbone.js /Knockout
Expectations
It would be very expensive to achieve the same responsiveness as windows app, as you will be messing with multiple technologies. Probably your users are going to hate the new app initially. Having skilled web designers on staff is very important
Based on our own experience with moving applications from desktop to web: carefuly inspect the architecture of your winforms applications and if possible - try to provide a web interface at the service or persistence level so that your windows applications use web services instead of directly talking to the database. Then you can let your users launch desktop modules from the application server using clickonce.
Such approach let us move to web quickly and users got the same GUI and a new way to access the application. In fact, it took like 3 or 4 months to redesign existing applications so that they use web services.
Then, we were replacing modules one by one, implementing them as web applications and maintaining both (clickonce and web) for a short period of time so that users were able to get used to new modules.
The migration of consecutive modules from clickonce to web was prioritized in an obvious way - we've started from modules that were used by most users. In fact, the initial release of the system has only one web forms module ready and remaining modules are being replaced for over 2 years now, one by one.

Using RIA Services directly within an ASP.NET MVC 2.0 project

I am starting a new project which will need a ASP.NET MVC 2.0 website, a Silverlight section and a Windows Phone 7 UI.
My plan was to use WCF RIA Services to create a set of services which would be used in all different UI projects. With the Silverlight project I would use the standard tool integration, the Windows Phone looks like it may have to be WCF Services exposed by the RIA Domain Services, but I'm not sure about the ASP.NET MVC website.
My initial thoughts I would simple reference the class library containing the Domain Services and use them directly. Could this be considered a viable approach to using RIA Domain Services in a ASP.NET MVC website?
Kind Regards
Michael
I know a long time has passed since this question was asked, but since I had to make such a decision, I might as well document it for the benefit of others.
I work in an environment where lots of legacy and new apps co-exist, with the legacy apps being phased out. So we've had to build interoperability between everything from MS Access, to web service end points in C#, VB, Web Forms, MVC 3, even Flex, Reporting Services...the list goes on.
One of the biggest pain points in a multiple-client scenario is the maintenance of interoperability over time. As data, requirements and delivery mechanisms change, keeping things smooth ends up taking a lot of resources.
My approach has been to create one and only one mechanism for reading a given source of data by defining 1) a model, 2) a serialization/deserialization layer and 3) a service layer. All projects that need to use XY_Data must use the XY_Service to get XY_Objects via the XY_Serializer. Direct db calls or stored procs, etc are allowed in the XY_Application. This allows me to drop in replacement DLLs (versioned) with bug fixes and upgrades without restarting anything. I hardly ever do a full publish.
So yes, what you're suggesting will work. I would recommend only that you rigorously enforce the single-source-of-truth and DRY policies both in your data and your APIs.

Migrating asp .net 2.0 application latest .net version(design question)

I have a web application built in the asp.net 2.0 MVC pattern.
Now the clients want to update this application with rich UI experience and the latest .net technologies.
Can anyone suggest whether I should use WPF or Silverlight: which one should I choose to change the application per the client requirement? I should be able to reuse my business layers and data layers, and thus reduce the time of development.
If I should choose one of these, please tell me the reasons and describe the requirements and what other guidelines I should keep in mind.
Thanks in advance
SA
First lets clarify the technologies:
WPF is a desktop technology - although you can run it via a web browser using XBAPs however this is basically just downloads and runs the XPF (so your users need to have everything that WPF needs - Windows, .NET 3.0+ etc..)
Silverlight is a proper web technology - meaning it runs across browsers and OS.
So which can you use:
From Silverlight/WPF you can call to web services meaning you can easily reuse your business layers, although you just may need to wrap them.
I would not recommend a full change though - I would adopt a hybrid approach of using Silverlight + MVC. Swap out the parts of the front end (view) that make sense with Silverlight but keeping the the ASP.NET MVC code. This not only means your change is small (you can test out a single change and get feedback from users such as maybe your user base doesn't have permission to install Silverlight and thus can't use it), and you keep the ability to unit test a large part of your code still.

Is ASP.NET MVC a bad choice for a large enterprise project?

We are about to embark on a large enterprise application. I am seriously considering using ASP.NET MVC because:
We need to use Microsoft technology (biz logic is all C#)
Performance is critical
I'd like to test as much as possible
My team has only used PHP for web development, but are very experienced with .NET winforms (so either way we have a learning curve). My concern is that some people have expressed concerns about ASP.NET MVC's scalability to large apps. But from what I read webforms have their own problems as well.
Should I be reconsidering webforms, or stick with my gut and use ASP.NET MVC?
Related:
Should I build my next web app in ASP.NET MVC?
https://stackoverflow.com/questions/521388/from-webforms-to-asp-net-mvc
ASP.NET webforms are heavyweight and drop a crapton of stuff on your webpages, both in html/javascript and serialized viewstate. I remember my first ASP.NET website causing the GC to blowed up because of all the short-lived objects being rehydrated from that godawful viewstate. Oh, when I was young and naive (i.e., 2 years ago)... You have to have a very good understanding of webforms to build scalable websites from them. Possible? Definitely. Easy? Not.
ASP.NET MVC is harder to code initially, but is SO much easier to develop than webforms. The hardest things to learn are 1) the conventions aka "magic strings", 2) Html + inline code aka ASP and 3) html forms.
With MVC, you can't get away with the state nightmare that is so common to webforms development, which means that means your webpages are meth-addict slim. It also means you have to code your state a little smarter. The code is also MUCH simpler and scales MUCH better than traditional webforms, imho.
Also, testing with ASP.NET is near impossible, due to the hard-coded and unmockable dependencies baked into the framework. ASP.NET MVC replaced all of these with System.Web.Abstractions members that are mockable wrappers around these badly-designed and untestable objects.
Run, don't walk, to MVC.
For the obvious-impared, if you use a framework that sits ontop of the ASP.NET framework, such as MVC or any other that you wrote or that somebody else wrote, OBVIOUSLY some of these remarks don't apply.
If, on the other hand, you code as early man did against the ASP.NET webforms model (e.g., Response.Write() in Page_Load), my comments apply.
Can you write code that's testable against ASP.NET? Sure. Can you do it without including special testing code you or somebody else wrote? Sure. If you have TypeMock.
ASP.NET WebForms is very much like Winforms and allows for RAD (rapid application development). It's very fast to get something in no-time. Problem with this is testing can be a major pain and if used for anything public facing can mean some major issues with ViewState. WebForms can hold state making things like a wizard a breeze to use.
ASP.NET MVC on the other hand can take a little longer to develop with and requires that devs understand how HTTP works. It's a stateless architecture meaning each request is it's own little world and usually has no knowledge of previous requests. The framework also allows for high testability.
As far as performance goes they're probably the same because ASP.NET MVC is just a framework built on top of the existing ASP.NET architecture. Though for client-side experience I'd say MVC is a bit faster.
As far as scalability I would say they're about the same as far as technical goes. How as for using the API and integrating it MVC would probably be a bit easier.
The website you're using right now to ask this version question is built on ASP.NET MVC and they have 2 web servers and a beefy db server.
ASP.NET MVC is not a problem for Enterprise, but neither is ASP.NET, Silverlight, etc. They are all UI technologies. The majority of your application logic should exist in libraries beneath the UI layer anyway, so pretty much any UI can be used.
We need to use Microsoft technology
Performance is critical
I'd like to test as much as possible
Based on the above, ASP.NET MVC will work. But, you can move the code down below the UI and test. If your algorithms are below the UI, you can tune them without altering the UI. And, if the UI layer is very thin, the perf hit for the UI is negligible.
No. One thing that the ASP.NET MVC has over ASP.NET Web Forms in terms of performance is that it doesn't make use of a control tree. The control tree consumes a lot of server side memory and keeps the garbage collector very busy on pages with many controls. I would argue that you would get superior performance from the ASP.NET MVC. The unit testing aspects of it are a real win to.
The flip side of this is that you can't use all of the handy out of the box controls that you get with ASP.NET Web Forms and you'll probably end up doing more client side JavaScript development so the initial development budget would probably need to be greater if you choose ASP.NET MVC over Web Forms, but you would have a superior solution for the long term.
Stick with your gut. ASP.NET MVC helps facilitate testing because almost the entire API derives from interfaces.
Have used WebForms for years and never liked them. Now use Asp.Net MVC for some years and this is so much better. Certainly woud recommend MVC.
Asp.Net MVC has an excellent architecture and is open source. So if you would identify bottelnecks in the http processing chain you could fix it. Most time you would be able to fix performance issues using one of the many extension points provided by Asp.Net MVC, like Binders as an example.
I would say go with MVC if you need or want its features . If you are building a line-of-business application such as an ERP or CRM system, I would use Webforms; if you are building a portal or community wiki type site I would go with MVC hands down. Ultimately it comes down to preference and what exactly your enterprise application needs to accomplish.
"With MVC, you can't get away with the state nightmare that is so common to webforms development, which means that means your webpages are meth-addict slim"
Upmodded for that quote!
My opinion: use ASP.NET Webforms.
Disable ViewState in the Web.Config.
There is no need to preserve state because everything you really need is in the Request object.
Use Javascript in conjunction with AJAX for data retrieval to render your UI controls client-side.
Create serverside wrappers in the form of control tags for your client-side component renderer.
This is how I've been working for ages now, and it's fast, reliable, testable and organized.
It does take some time to setup a decent framework for this working method, but eventually it will rule.
I rather have no spaghetti code like MVC. Been there with PERL/PHP and classic ASP.
Everything I've read about asp.net MVC says that it is able to serve up more page requests than asp.net webforms.
I have some doubts about its stability and security though. Both of these stem from the fact that it's not even released and even with the RC we saw some changes to the framework. I am sure there will be more changes as time goes on and things are found. It's new so there are not really "best practices" out for it and there is a not a wealth of experience out there detailing the small issues or gotchas that you might run into.
I've been using it and it does result in smaller pages and faster performance. But there are so many things I can do in webforms that I have no idea how to do with mvc because mvc does not promote the use of the webforms controls.
If you're able to use stored procedures then you don't need a big middle-tier like those generated by MVC. All you have to do is pass XML to your stored procs through a simple HTTP handler, get results back from a stored proc, and convert the results to JSON. MVC and other middle-tier stuff only serves to make money for companies that sell IDEs like VS.

Resources