Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have an web site built in ASP.NET. It is a business website that works with a lot of data.
I had a lot of problems, especially of speed and effectiveness, so I did what I can with ajax, and speed greatly improved.
I wonder if I should switch the web site to ASP.NET MVC?
I don't know ASP.NET MVC very deeply, so I want to know if I should invest in it, the main question is: Is ASP.NET MVC faster and more effective than regular ASP.NET?
I believe that ASP.NET MVC is (if not, already has) becoming the mainstream way to develop websites in using the ASP.NET stack. There is a lot less emphasis on ASP.NET WebForms in the last few years, which hints that MVC is the sensible choice for starting new projects (Note: WebForms is still a popular choice for some devs though, I'm not saying don't use it ever. There's still a place for it.)
Regards migrating existing ASP.NET WebForms apps, I would be a little cautious. Don't switch to another technology unless you have a very, very good reason for doing so. Depending of factors such as the amount of code, the design, it could take a lot of effort to convert an ASP.NET WebForms project to ASP.NET MVC.
In your situation you mention performance issues, which made you consider moving to ASP.NET MVC. I would look more into why your site is not performing as you would like. Use a profiler to measure which code paths are taking the longest ot execute. There are plenty of sites built using ASP.NET WebForms which perform to high-scale, so I would not make the mistake of moving to another technology in order to solve a performance problem.
It depends on where your current issues are.
Should you learn MVC - definitely.
Should you write new applications in MVC - sure.
Should you migrate old applications - depends.
What's the architecture of the current application?
How much time/resources do you have to allocate to a rewrite vs fire-fighting the existing app?
Is there a clear data or middle tier or is the data access built into each page code behind? Many applications are written so that the front-end can be swapped easily or called from other applications (eg via an API) but many webforms applications (not all) are written without these considerations and so it wouldn't be a swap out but a complete rewrite of the application.
What are the current issues other than "it's a bit slow"? For example I've seen an app that loaded the entire data model into memory for each page - simply changing the front-end would make no difference in this case as the cause of slowness was the data loading. Changing the architecture to load only what was needed significantly increased the speed.
The improvements you can get from using MVC aren't necessarily the business level ones you might expect. There are plenty of sites that go into this in more details, here's some to get you going:
MVC generates (much) cleaner HTML in the output - so pages are easier to develop/maintain and easier for developing UI interactions in javascript.
MVC has a much improved pipeline which can be hooked into, eg for adding action filters.
IoC/DI is hugely easier in MVC
Separates the model/controller code from the view html
Your application users won't care about any of these.
I have the same situation with one of my clients and after learning the MEAN stack and working with another company who made the transition to Nancy. I would recommend doing a REST API with Nancy and a pure front end with Angular or another Javascript front end. This will allow much faster response and flexibility down the road. Plus it will give you more flexibilty if you ever want to expose your API to other apps.
I tried to move from Web Forms to MVC and it was not very easy for me at the time.
You can use Asp.net Web Forms, with more ajax and less post backs and less view state usage if you do not want to move to asp.net mvc.
Asp.net MVC on other hand is very good with light wight pages and capabilities to blend in with client side ajax based solutions. And its architecture supports scale ability.
I think you should definitely take the time to learn MVC, as it is becoming a more marketable skill and future projects are more likely to call for it.
With respect to being faster and more effective, it is somewhat. First off, WebForms have a lot of overhead in order to have this windows-forms-like behavior (which, frankly, has never been a perfect fit for web pages). Second, MVC tends to render HTML that is much cleaner without the view state or long IDs. So those two items can make it faster. (Of course, if you are having speed issues you also need to look hard at your host server.)
With respect to rewriting your current project to use MVC, that's a more difficult question that only you can answer. WebForms still work and will probably be supported by Visual Studio for many years to come. Depending on your project, rewriting it can be a costly task. So you'll need to decide if it's worth it. That said, I hope to rewrite all my webforms websites using MVC as time allows, although part of the reason is just to update the look and make them more responsive to mobile devices.
Related
I watched a little introduction into ASP.NET Dynamic Data, and I noticed this option to create a data driven website for the first time. I have a database with a few tables, just created a Dynamic Data application out of my database and well... my application with a lot of nicely looking web pages, navigation between them and all kinds of CRUD operations was finished after 3 minutes.
OK, seriously, it isn't finished of course. There is a lot of custom logic to introduce, design to change, and also pages or relationships to remove I don't want actually to see in the web application.
But now I am wondering if ASP.NET Dynamic Data is at least a viable starting point or do I better start from scratch and create page by page? I could imagine that it might be useful to create a quick database maintenance web interface but is it good for a very customized web application? Is it in the end more complicated to modify the scaffold than building up everything from the ground?
I'm very interested in your experiences or recommendations regarding Dynamic Data! Thanks in advance!
I could never wrap my ahead around it enough to get any use out of it. At first, I thought this was Microsoft's answer to Ruby on Rails, and I was looking for the same benefit. I don't it comes close to having the same benefits. When I then compare it to a CMS (DotNetNuke, Sharepoint, Drupal, etc) it then looks really underpowered. Compared to ASP.NET MVC, it seems like going the wrong way from basic ASP.NET (MVC is removing bad abstractions from ASP.NET, while DD is adding even more abstractions).
Personally I'd rather build something from scratch in ASP.NET MVC, though my day job is regular ASP.NET. I'm also learning Drupal as I haven't found the sweet spot with ASP.NET based CMSes. One thing at at a jobsite you're going to want to use technologies everyone else knows. So I think that limits where knowing Dynamic Data is generally useful, as basically any legacy application won't be using it and you're unlikely to find a team with existing ASP.NET Dynamic Data experience.
The quick scaffolding is spiffy but at the end of the day I don't think it will make web development easier.
I very like ASP.NET Dynamic Data as it is a fast way for creating data driven applications. Customization is not a complicated task.
I wrote a corporate website with this technology from the scratch - it takes appr. 2 months for all. So my point of view that this is a good starting point for web applications development.
if your archetecture resembles ASP.NET Dynamic Data or DotNetNuke or some other starter kit, go for it, if
application is small to medium sized
you do not have strict deadlines
you are learning the technology.
otherwise or when you will be skilled in particular technology, you will prefer yourself working from scratch as it gives you more freedom and space for the implementation of ideas.
For e.g, one reason for the breakthrough for Asp.Net MVC had was many .Net developers wanted freedom over the development / architecture / flow and rendering (HTML) of the product they were building. Asp.Net WebForms does provide solid and vast grounds for swift development and templates but developers had to go according to the architecture. This freedom is available under MVC and developers can make use of nearly all Libraries and skill set available and go their own way.
one successful sample is Stackoverflow.com itself
hope this helps
We are going to develop a website in ASP.NET. So is it better to use MVC or web forms.
It depends on what kind of site you want to build and your knowledge and experience creating websites.
If you know your stuff and are confident in your ability to work "close to the metal" (as it were) I would imagine that you could build a faster website using ASP.NET MVC since you would be able to optimize your site to have as little overhead as possible. However it is more than possible to build a very fast site using standard ASP.NET as well so it really depends on exactly on the requirements of your project.
My completely unscientific opinion: Yes; ASP.NET MVC is faster than web forms.
ASP.NET MVC gives screen pops on the order of 1 to 2 seconds. Web forms is more like 3 to 5 seconds.
I don't know if they switched to ASP.NET MVC when they did the lightweight version of the MSDN library, but the speed improvement is similar to what I described. And let me tell you, the usability improvement is like night and day.
YMMV
Personally, I don't think there are big performance gap between asp.net mvc and web form. Because they actually employ the same underlying engine. In most cases, what makes performance a problem is how developers write their code, and the structure of the application.
Usually, people tend to compare mvc and web form on the elegance, maintainability.
http://weblogs.asp.net/shijuvarghese/archive/2008/07/09/asp-net-mvc-vs-asp-net-web-form.aspx
Web Forms and MVC each have their strengths. Web Forms typically has the familiar code-behind style of coding where you hook up a handler for something like a button click and write the code to handle it. MVC has a more separations of concerns style of coding and is generally more unit testable.
It all depends on your coding preferences and time required to deliver the project with respect to learning curves.
I would imagine this question has been answered a million times on this site an many other blogs.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I plan on building a simple, yet high usage webapp and need to settle on an architecture.
basic server side logic / dynamic db
driven content about half a dozen to
a dozen pages serving up all said
content
no need for URL rewriting,
pretty simple page flow/routing
The objective is to publish this app to use the least amount of bandwidth, memory, and CPU as possible. That said, my options are to
build in ASP.NET MVC
build in webforms with viewstate
disabled
build using .ashx handlers with code
that concatenates all HTML output
into strings that it spits out
Which is the most lightweight solution?
I appreciate the responses so far, but i'm not asking for the best solution. This is a simple app, and i want the solution that will use the fewest machine/network resources.
HttpHandlers are the most lightweight from your list of 3 options.
Personally, I would use ASP.NET MVC because it gives you a richer development environment with very little extra server overhead, especially if u turn most things off ..
eg. roles, etc.
Also use IIS7 intergrated mode and turn as much IIS7 settings off etc.
HttpHandlers are the most light weight, because the interface behind the ASHX file is IHttpHandler which is the basis of the Page object that is used both for Web Forms and MVC.
Omit the third option because it is very hard to control the application if it is all built using HttpHandlers.
basic server side logic / dynamic db
driven content about half a dozen to
One of the major benefits of ASP.NET MVC is the ease of the separation of concerns. +1
a dozen pages serving up all said
content no need for URL rewriting,
pretty simple page flow/routing
ASP.NET MVC will give you an easy interface to set your routes, a lightweight,clear, and controllable views. +1
WebForms are going to be the heaviest in most cases. ASP.Net MVC is quite lightweight and surprisingly fast compared to WebForms.
Building an application using HttpHandlers to serve pages may be fast when serving static content, but if you plan to use some sort of templating to serve dynamic data, you're going to cause yourself a lot of undue work. As for performance, it's hard to say with this option because your templating could be nasty or possibly not.
ASP.NET MVC, Web Forms and the Generic Handler (.ashx) are all HttpHandlers implementing the IHttpHandler interface.
Out of these options the Generic Handler (.ashx) would be the most lightweight.
ASp.NET MVC is as close as you can get to HtTP and Html.
You should use MVC, because you have a lot of more control about the generated client code than in WebForms, and is simpler than ashx handlers.
MVC very much gives you more control over HTML produced. So, from a bandwidth perspective, it definitely has better performance. With this may also come conciseness of code to generate this HTML.
However, MVC doe not improve business/data layer, or database performance, it just separates them. If you want to analyze, having multiple layers does not improve performance, just the structure of the program, which in turn may lend itself to methods for adding more performance.
A down side to MVC is learning how to think MVC and learning how to use the framework. If that is not an issue, go for MVC, it will teach you some good habits, if you don't have them already.
And finally, HTTP Handlers are not really meant for being used in this way, they are for things like file proxies.
Last week at Mix '09, the final version of ASP.NET MVC 1.0 was released.
Some of the stated benefits of this framework are:
Clear separation of concerns
Testability - support for Test-Driven Development
Fine-grained control over HTML and JavaScript
Intuitive URLs
Now, Microsoft are being careful to tout this as being "an alternative, not a replacement, for ASP.NET Web Forms", but given the advantages mentioned above, I'm wondering:
How long will it be until "classic" ASP.NET Web Forms is considered to be a "legacy" framework?
If you were kicking off the development of a new .NET web project today, why would you choose to use Web Forms instead of the ASP.NET MVC offering?
Good questions. I think ultimately, the answer is going to be the development team's expertise and the project needs that will decide that. ASP.NET web forms is so heavily used that it likely isn't going away anytime soon. Plus, there are so many custom controls and third-party support such as components and books. The main benefit of web forms is how easy it is to get a dynamic website up and going. It really is a RAD way of developing websites.
However, once that team has more experience with creating larger websites with much higher demands in terms of scalability, reliability, and test-ability, then they will look towards other solutions for that. In this case, they will realize that web forms are harder for unit-testing. They may also see that viewstates reduce performance and look for possible solutions.
Although MVC has the stated benefits, it is unlikely that anyone will convert their sites to use this new framework right away or ever. Plus, it requires the team to learn the new technology, and work out the new bugs. The team will have to learn new ways to do the exact same thing. For example, how easy is it to support uploading a file using MVC?
As I saw recently, there isn't a reason you can't create a site using MVC and web forms together. So you may see more hybrids in the near future. But I doubt that web forms will ever go away.
I kind of think about web forms like the way VB1 changed the way Windows applications are created on the desktop. To this day, the RAD way of creating application still exists and will never go away.
Keep in mind that MVC STILL uses WebForms for it's default View Engine. Sure, you can replace it with another one, but WebForms is still a core part of it.
Also, not everyone prefers to tightly control the HTML or the Routing. That's not my attitude, but some people just want their job done with the smallest effort.
And aren't .asmx Files technically part of the "old" Model as well? I can say for sure that a lot of people would not like to see them go away.
Still, I personally see ASP.net MVC becoming the main Web Engine for ASP.net in the future, although not in .net 4.0 yet.
You're asking when a newly-released web platform, ASP.NET MVC, will replace Web Forms, which has been around for seven years.
If we'd been crying out for ASP.NET MVC for the past seven years, then it wouldn't have taken seven years before ASP.NET MVC was released. The fact is, not everyone sees a need for this. Many of us have been creating complex, highly-scalable web applications for most of those seven years.
We even knew how to make them testable, and to separate presentation from business logic and data access. ASP.NET MVC may enforce this separation, but I've done it by using coding standards and code reviews, and by saying, "there's no unit test for that", and "get that business logic out of the UI".
Also, if I really needed more control of the HTML, I would write my own control to generate the HTML.
I do not believe WebForms will ever retire.
I've been using WebForms at work in business applications and MVC at home for some private things. Though I really like MVC I do not see how this could be possible to implement really complex UI logic with HTML/CSS/JavaScript. It will quickly become unmanageable and will be quite unsecure since JavaScript can be switched off to prevent disabling some controls or hiding some information. On the contrary, turning off JavaScript with WebForms will virtually turn the page dead for any action, either authorized or not.
Both platforms will continue to evolve. For general web sites and HTML/CSS lovers MVC is a way to go, with complex applications you would want object-oriented architecture and artificial event handling even though it abstracts you from the stateless nature of HTTP.
So, pick up what is best for you.
P.S. Dropping WebForms altogether will jeopardize the future of numerous projects and companies throughout the world. Microsoft folks would not want to become an object of hatred and the trigger that started the third world war.
WebForms will still have a place for those that want a pseudo-stateless web application that they can easily put together by dragging and dropping. For those that don't have to or want to understand how HTTP works. It's the ultimate in RAD for web applications.
ASP.NET MVC on the other hands allows much more finer control at the cost of more responsibility. You get complete control over your HTML however that means you have to sanitize/encode your output yourself. Your application for the most part has to be completely stateless and for some ASP.NET WebForms/Windows WinForms developers that it's a bit hard to wrap their mind around.
I don't think either will ever dominate the other though one may be favored.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm doing some maintenance on a classic ASP application for my client, and as I'm looking through the ASP, the following question comes to mind - would it be easier to convert a classic ASP app to ASP.NET MVC or ASP.NET WebForms?
In many ways, it appears that at least the HTML of ASP might be easier to convert to MVC than it would be to rip out the HTML chunks and turn them into ASP.NET controls, repeaters, datagrids, etc. Plus having to add in handling and logic for ViewState, etc. might be added work.
I don't think my client will be requesting any upgrade like this, so this is just theoretical.
Let's assume that this ASP code is written very well (which isn't always true of course) so really the question is, will a best-case-well-designed ASP site migrate better to MVC than WebForms?
(Note that I'm very new to ASP.NET MVC, so I might be missing something crucial here).
It depends a lot on how the classic asp app is structured.
The server tag mixed in with HTML is similar to asp.net mvc but MVC is not as messy (or not supposed to be). You might be able to move the classic asp presentation code to a MVC view easier than to a web form. Also classic asp apps were usually developed with the statelessness of the web in mind. There probably is not anything in your classic asp that matches postabacks or viewstate. Classic ASP also uses normal html elements as opposed to asp.net webform controls. In these respects it matches MVC a lot closer than webforms.
If you do not know asp.net webforms or asp.net mvc I would say MVC is the way to go.
If you know webforms very well and don't know much about MVC I would say webforms is the way to go.
But, if your client for some reason does want a redevelopment of the site I would say go with MVC. It's always nice to have a client pay for part of your experience development as long as you can deliver.
On another note I'm always taken aback when I come across a client who wants me to do work on their classic asp site. In every single case the site is a mess. The worse part is that they are usually filled with huge security holes.
I think in a lot of cases it could be easier to convert to MVC than Webforms. Most classic ASP apps demonstrate very little separation of concerns so the biggest task is probably exactly that, seperating out the logic into data access, business logic, business entities and UI components. In doing that it could well be easier to convert the inline ASP code to a view, the business logic into controllers and the business entities into the model.
I don't think one would be easier to convert then the other.
You can code ASP.NET almost the same as you code ASP if you wanted putting a few crucial elements in the codebehind that you could access in the aspx. No databinding, no gridview and no repeater. The view state is there to help you can is easy to figure out, it is not necessary to use it if you don't want and can be turned off in the web.config and turned on with a page attribute. Web forms also have an AspCompat mode which allows access to Request and Response objects or asp, which will allow for page by page conversion if desired.
As for MVC.net, the method for displaying the HTML is quite similar. That in my opinion is where the similarities end. You would still need to separate out all you logic into the MVC model.
Coming from ASP and going to Web.Form and now MVC.Net I can tell you that WebForms were a little annoying/frustrating to learn, with 90% of the MS tutorials teaching you the worst possible habits IE (SQL connections on the page, dragging datasets around in designers). However, once you get past that one is able to do a lot of thing much more quickly then in asp(pagination or build a simple datatable with editing for example), I have however STILL never seen a large webforms project with an n-tier design that I thought was easy to follow, implement and use.
MVC.NET is like a godsend. It forces patterns and practices down your throat, it has strict rules that are adhered to by most. It allows for easy code coverage and separation of concerns. After being frustrated with webforms for years it finally feels like I am not hacking things together when attempting to do something that I cant drag off the tool bar.
I personally would try webforms so you will know how much better MVC is when you start using it.
There is more to ASP.NET-MVC than the apparent similarities between view code and ASP inline code. There is all the Model and Controller parts to consider which is very different from the way most ASP is written.
That said I would say that MVC would be the best place to start.
IMO WebForms attempt to hide html too much for my liking and may cause your project to take longer than you would like due to converting a lot of html into the webforms controls.
On the other hand MVC allows you to reuse some of this logic while making your application much more maintainable and with the appropriate Architectural Pattern your application can be developed and refactored much quicker than any WebForms project.
I say MVC all the way!
Either way, it's always best to start from scratch and implemented only the logic.
I started ASP a long time ago (more than 12 years ago) and only in 2006 I moved to ASP.NET 2.0, not even today I know all, but I do know pretty much what I do everyday at work.
In my opinion now, and looking back to my knowledge of ASP I would go to Web Forms instead of MVC, first, it's a language that it's in the "market" some some yeras now and very used across the world, while MVC is still in Beta, so, not suitable for production environment (says Microsoft - even if this site is written in MVC).
I do tend to make confusion with MVC diagram still, and there are more tricks than I want to learn if I need to do a fast change of one ASP project.
It depends. The ASP.NET MVC is no silver bullet and in many ways takes a few steps backwards in terms of developer productivity.
If you have a tight budget and need to get this done fast I believe ASP.Net is the way to go since it has the wealth of controls like grids, paging, validation etc that you can use right out of the box. Using these controls will no doubt save a lot of dev time. All of these controls that most consider pedestrian by now in ASP.NET all have to be created from scratch or taken from the Internet when you use the ASP.NET MVC project.
On the other hand if you have the time and budget now and going forward, and you want to have a solution that is rock solid, and more easily lends itself to test driven development, the ASP.NET MVC is probably the best choice.
Definately ASP.NET MVC is better in terms of style. (That said, you don't have to use Repeaters and other silly controls in a WebForms app, you can simply use inline code just like you would in MVC.)
MVC in general though would be an easier port, give you a better structure and be a more pleasant experience.
Web Forms is more object-oriented, while MVC is like classic ASP on top of .NET code. Model design should be the same using Web Forms or MVC. The only difference is that Web Forms has an object-oriented abstraction to the UI and MVC uses functions and code snippets instead of classes to organize UI code.
ASP.NET MVC is better than Web Forms for automated unit testing of the UI. However, automated unit testing in general is bad practice and even worse for the UI. Manual testing is the best way to build a quality application and to make the best use of development time. Creating automated unit tests is a waste of time and you end up with junk code to maintain with the core code. Lots of developers like automated unit tests because they think they are proof their application works, which is false. They also are trying to avoid designing applications using UML so they are using test driven development to design using code which is responsible for poorly designed applications. With TDD, you are refactoring code you wrote poorly without thinking about the big picture using models in the first place.
So MVC is useless. Web Forms uses a better object oriented model whereas MVC is more like old style classic ASP and other older design patterns. This is 2010 and MVC is dead. Web Forms is like ORM for the UI.