i have very strict requirements for performance on a large data entry application. You can imagine a single form with hundreds of fields, tabs, modal popups and similar.
The question is, what is the best Ajax architecture that i can implement to make it fast?
i was thinking about lightweight json async calls on the client, and async operations on the server. I was also considering HTML templates on the client, instead of building html on the server.
Let me know what you think.
Thanks in advance.
Use a combination of jQuery and HTML for the client and .net methods in the server-side callbacks. Async calls are good, but not always the best choice, remember that. Basically, use as few server-side components as possible because it generates much markup
there are also techinques for improving performance like caching. This can be done many places, for example on the .aspx page or on the web-server itself.
If you can, turn off the viewstate. This can generate much unnecessary markup
I would use a combination of JQuery ajax and ASP.NET MVC 3. These two combined provide an easy way to make fully async applications and due to the nature of MVC you can have HTML templates, most of which are already available through the MVC3 template.
Ok, I hate to say it.. but what you want is impossible. You cannot have a form with hudreds of elements on it, and still have it perform well. Of course "perform well" is subjective.. but the only way to get good performance over a high latency network connection with variable bandwidth (like the internet) is to work with very small sets of elements.
Using AJAX-Enabled WCF Services, JQuery and JQuery Templates can give you a good network throughput performance and a good user experience for your users.
But this comes with a price. Developing, debugging and mantaining such an application is very hard considered to a regularly developed ASP.NET application.
It's a trade-off, and if you ask me I would suggest you to go for the traditional way and make some improvements to your application interface, such as dividing forms, implementing a save-continue wizard-like type input screens. You can still use JQuery to improve user experience and caching to improve application performance. Keeping an eye on view-state and using UpdatePanel's as necessary could help even more.
Related
I'm building a Bridge game.
The main page, where you play the game, boast some 200 controls, like buttons that represents the 52 cards, 26 others for won / lost tricks, plenty of text fields... You name it, total some 200.
Actually its been already built and runs under Winforms model, but with the unavoidable question of implementing .NET 4.0 onto user's machine that must run Windows, and installing the software.
Hence I'm considering creating an ASP version (no PHP please, since I'm fluent in VB, and ignorant in C, Java, PHP and the likes).
Is that a "real" option or am I dreaming?
Will it run smoothly for users with a 2MB DSL connection?
Oh, by the way, no MVC please, I'm too old for that sort of sh...t :->
Can it be done? Sure.
The problem for you might be that to do it effectivly you will need to use HTML, CSS, Javascript and the like.
What most likely would be a good idea for you here would be to go the route of Silverlight. It will give you a more rich UI experience and will allow you to code in VB entirely.
I don't see using ASP.BET directly as a good option here. To make it look smooth, you would have to use javascript heavily. I thing you would be better off with Flash.
If you prefer to use pure HTML/Javascript/CSS you can create rich Web UI's by modifying the Document's Object Model (DOM). With little knowledge of Javascript and the usage of some library like: scriptaculus, prototype, sarissa, jquery, you can get rich interfaces. You should take a look at some of these libraries mainly scriptaculus because the set of animations it provides. Another javascript library made for game development is gameQuery.
With that many controls on an ASP.NET page your view state will be gigantic. If you plan on only serving up a couple of games at once then it shouldn't be a problem but you have to actually start thinking about bandwidth with that large of a viewstate. You would be better off with a DOM/jQuery type interface which displayed static images for the cards. All interaction can be handled client side and validated with a server side call.
This might be the perfect opportunity to learn javascript :). Remember each language you learn is another tool in your toolbox. The engineer with the most tools usually wins :).
I have read several other posts here, so i get the idea on the pro vs. cons, especially having full control over the rendered html code etc. (in MVC).
My question is regarding the UI controls: In MVC, i will have to write all UI controls myself (or the html equivalent). Now is that not going to be very difficult?
The reason why these 3rd party vendors for asp.net are there is just because of the fact that it is difficult to write UI controls for ASP.NET all by ourselves, and be able to target to all web browsers, and also that we are better off concentrating our time on the business logic rather than spending the whole lot of time writing the UI controls HTML code ourselves.
I understand that this feature gets us the full control over the final html, but is it not counter-productive to do this UI bit ourselves. If it was so easy to write them ourselves, how come these 3-rd party vendors are all living now. We could have done this all by ourselves all these years of WebForms days.
I am sure i am missing something here or being a little stupid, but please enlighten me as to what i am missing in specific regard to the UI bit being written by ourselves.
Just because i get full control over the program by writing in IL code, do we go and do that? We still use C# and things like that - So that theory of "having full control over html" - i am not bought into that idea.
Please help in getting my head around this UI bit.
Other things i understand, about the separation of concern, TDD based development possible with MVC etc.
But why would i go around writing the UI controls all by myself - it is a bit a work isn't it?
The thing is:
If you want to master in web development you have to master HTML + CSS + Javascript
And with WebForms you have to learn the WebForms way to do it, but with MVC you have the power of .Net with the freedom to generate the HTML + CSS + Javascript you want.
Here's a new rant on the subject http://www.charliedigital.com/PermaLink,guid,6dcb0333-9d70-40c7-975b-0ff4011c4661.aspx
Problem is, ASP.NET MVC is much younger product than ASP.NET. For many years 3rd party companies have been developing TONS of reusable components, and I believe that it is only a matter of time before comparable set of controls will be available for ASP.NET MVC.
If you really need very rich GUI with 3rd party controls, and you can't rewrite them in acceptable time - stick with asp.net. Altough in my opinion, MVC gives you tons of power it wouldn't be wise to spend much more time rewriting controls than you can save. If you can live without controls, and like MVC concepts - use MVC, and you'll most certainly see 3rd party solutions as soon as they'll there is growing market (maybe thay've already noticed that, I don't know) for mvc extensions.
I believe that the UI and the user experience are vital to the success of a web app. Making the page intuitive and easy to use, minimizing the amount of navigation the user has to do to get the job done, and providing effective feedback and interactivity can make all the difference between a site that users want to use and one that they avoid.
If you are trying to attract users on a public website, a pleasing appearance and excellent usability are key to building repeat visits.
If you are writing an intranet app to be used by hundreds or thousands of employees all day long -- as I mostly do -- making the UI efficient and easy to use really means a lot to your users.
So, I wouldn't downplay the importance of the UI. It isn't a nuisance. It's a key part of the user experience. I suggest that a web developer should embrace whatever tools and strategies that will get the job done. That often means coding the UI controls yourself. Or working with a teammate who likes doing that part of the work.
I recently refactored a very complex website using ASP.NET + handworked javascript to MVC + jQuery. The complexity of the code was reduced by 50%-75% and became much more testable. I replaced all the complex webcontrols I had to write (with a steep learning curve I had to overcome) with very simple HtmlHelper methods.
Don't forget, when you use custom webcontrols, you are given a very static UI by the control developer. With raw HTML, you can take advantage of styles and ui developed by the whole web industry.
Increased simplicity, decreased development time, testability, flexibility in UI... I don't want to go back.
You also have to remember that ASP.NET MVC is just the first release. I don't think there is intrinsically any reason why you couldn't have the equivalent of server controls to enable certain tasks - remember, there are many server controls that don't generate any mark-up (such as the Repeater, PlaceHolder, ListView). These type of controls could be useful in a future MVC setting, I think.
I believe that ASP.net came around when lots of developers were still used to doing desktop applications and just beginning web development. AT that point in time abstracting the details of the web with controls and post backs was a great way to get people started. At that point we weren't trying to perfect the web, we just wanted to get on it!
Now that the web has matured and we've all slowly learned about html, css, javascript and the likes we want to optimize our websites for our own needs and we don't want to depend on ASP.net Forms controls to control the fine details of our websites.
In summary, I think this is about the natural evolution of many developers from the desktop to the web
I for one, am very thankful that you cannot use ASP.NET controls in MVC.
Controls, as many have already pointed out, are just server side blocks of code that render HTML and javascript on your behalf. Things like a datagrid are great, until someone asks you to make a slight modification, like having a delete confirmation alert, and then it seems impossible to do certain tasks.
The good news is that there are very powerful jQuery tools written to help you. jQgrid is a great grid replacement that does WAY more than the ASP.NET grid...
http://www.trirand.com/blog/
jsTree is a treeview that is fantastic. Again with the jQuery....
http://www.jstree.com/
And the truth is that most things you can do with razor, HTML, javascript and CSS. It's so simple that it's just stupid.
It's hard for people like myself who were web forms developers to grasp MVC and why you should use it because it's so simple. It's difficult to let go of the complexity of conventional ASP.NET. But it feels so good when you do.
And don't mix web forms with MVC. You can do it, but you will wish you hadn't.
Here is the key thing that I think you are missing. When ASP.NET is no longer the MS way of doing things...you will eventually be forced to move on and do something else. I have programmed in perl, ASP classic, then ColdFusion, then PHP, then ASP.NET web forms, then ASP.NET MVC...the only thing that they all have in common is the underlying database, design patterns, best practices for a given set of technology AND...HTML, JavaScript, CSS, and Photoshop.
No one is asking you to learn MVC. No one is telling you to not use WebForms. However, complaining that you have to write a raw UI is not going to get you very far in this industry. You should be learning something new every day...and it sounds like some time spent on HTML and CSS would be a great place to start your focus!
The biggest problem you have with relying on third party controls is when a client asks you to do something that the third party controls don't cover. If you can't replicate their complexity plus the added feature request on your own you are skirting a possible failure in your professional livelihood! You will need to know how to do it all...eventually!
I generally suggest that you embrace new technologies. You don't have to use them...but you should at least know how. This way you will know what the best tool is for any given project.
I've been wondering - what's an equivalent of 'control' from webforms in asp.net mvc? It's not a partial view for sure. What else it can be? Controller + partial views via partial requests?
Maybe i'm dumb, blind or both, but i haven't seen any 'control' for asp.net mvc. Just a lot of code snippets to accomplish one specific thing or another.
I believe that asp.net mvc is quite unfriendly with rapid development. Only way out of this problem - a lot of open source code (like MvcContrib), tutorials, sample applications & most important - slightly smarter developers.
You do not have to replace Webforms controls with something else from MVC. Just mix them - http://www.hanselman.com/blog/PlugInHybridsASPNETWebFormsAndASPMVCAndASPNETDynamicDataSideBySide.aspx
Well, I was also wondering how to use 3rd party controls in ASP.NET MVC. Obviously, and contrary to some answers here, it had to be possible.
As much time has passed since the question was asked, the industry has evolved. So I've searched and found (but havent' yet tested) solutions such as Telerik Extensions for ASP.NET MVC .
I'm posting this answer here mainly to support other MVC newbees such as myself - Just Google
"asp.net mvc" controls
I've seen a few blog posts and tutorials overviewing mixing in jQuery and the UI elements for Views in a .NET MVC web app. But usually targeted at developers with a comprehensive grasp of the full dev cycle and variations of back/middle tier technologies.
As the front end developer I'm pitching a jQuery-only UI to the back-end dev - he cautions against a non-webforms interface for sake of the code maturity pov.
I'm trying to hit back with "well...it's your pattern ...isn't it elemental to MVC? No logic in the view? I'm reading that to be 'server-side stuff'. You just serialize the properties i'm asking for, or better...let me easily discover what you _can send me...i'll be able to implement the UI via jQuery UI."
So how valid is my position?
Can jQuery's grid be expected to handle at least the bottom 85% of .net's native control (low-to-moderate capacities # of rows)?
How about in-line editing? ...from the grid?
Would working exclusively in Web Services simplify his life at all? and if so, wouldn't that be logical way to build a .net-to-jQuery relationship? - ajax liaisoning twixt server (.net WS methods) and client?
mny thx
--steve...
Don't fight the platform. That way lies pain and suffering.
The MVC view objects are vastly different than asp.net webforms with server controls--you get straight up html. You get jquery and ajax basically for free, with (almost) magic server side ajax call processing.
They are designed to do what you ask. Writing your own jquery ui is reinventing the wheel.
Not only would it be a ton of extra work for no gain. You would be the only developer around trying to do that, and when you needed help, few could offer advice.
If this is an admin interface, and the client has agreed that users must have javascript enabled then I think using javascript to build widgets on the page is a better option than using the asp.net server controls. If however this is a public facing website I would argue that a pure html and css approach is much better, and then use javascript to progressively enhance the page!
Now I dont ever advocate using asp.net server controls, because they spit out poor markup and they are overly complicated to use. Instead I have been using jQuery to do the grunt work and dom querying and traversing. I also dont advocate using jQuery UI because they are missing some very essential widgets, for example no datatable, no treeview etc. I know that there are lots of plugins for jQuery but they are not componentised and therefore each plugin needs to reinvent the wheel to achieve everything it needs. Once you have included all your plugin libraries and css you often end up with a very large page footprint. Also each plugin often has a different home page and documentation that may or may not be up to scratch.
I think that the best UI library is YUI, and you can easily combine it with jQuery. Because each widget is made up from core components the overall weight of download is smaller. Also you have all the documentation in one place with 100's of working examples. Also it means working with the same set of javascript patterns across the board, so with each widget you learn more and more about the library. Hopefully jQuery UI will catch up, but personally I am looking forward to YUI 3 which for me might mean dropping jQuery altogether...
jQuery is a very mature library. It is used by thousands of people across the internet, and I dont think I have ever encountered a bug. YUI is dogfooded by YAHOO so it too is battle hardened.
One thing I did not mention to you is that I am using the default webforms view engine with asp.net mvc. I think it is still the best option as you get intellisense and also Resharper refactoring even searches your views, and the static solution anaylsis can find code errors in your views.
For building my markup I have been using MvcContrib Fluent Html but you could also checkout this article that advocated the DRY principal very well.
I'm in the process of designing a solution for the company I work at (but have just resigned from) which has a very complex application process in it. The process is close to 10 steps (including T&C's and preview) and also has some very tricky UI-level business rules (mostly driven by a legacy tie-in system).
Essentially the validation is driven by what has been selected on previous forms, and not just the one directly prior.
The solution has already been decided as an ASP.NET application but the more I design the solution the more it's looking like it's going to be very difficult to achieve in a stateless environment. It's going to either end up with query string parameters, hidden variables on the page, viewState or session to pass the information around.
Then I had it suggested that I look at Silverlight, to give it a more stateful environment and make it easier to handle the passing of the parameters around.
I've never done anything with Silverlight, other than watch presentations, so I've got no hands-on experience with it, but from everything I've read I think that it does have potential to solve some of the major problems which I can see coming out of trying to do this with standard ASP.NET.
So how do I go about:
Is Silverlight a viable option considering what I mentioned above?
Pitching Silverlight to a company without any Silverlight skills?
How do you deal with the "but it requires a browser plugin" argument?
From what you're saying your problem is about keeping state between multiple pages/forms. Sessions are good for that (not so much the query params or hidden variables as those can be tampered with, just having to think about that possibility when developing your app will slow you down.) I'd recommend that as simplest all round.
However, you can also put several forms on one page and submit them together, but have it look like different pages using javascript. It wouldn't be too hard to do with any decent javascript library, but I recommend jQuery (Microsoft is adopting, over their own, as the standard for ASP.NET)
Same as the silverlight problem if your company doesn't have many skills in javascript, but at least it doesn't require a plugin.
Don't get me wrong, I love silverlight, I love it so much that when it gets market share similar to flash, I'd drop HTML/css/javascript. It just doesn't seem to fit for you though.
I currently work for a company that builds its primary LOB app in Silverlight.
Silverlight may be a good choice for what you are trying to do, but consider:
Using Silverlight won't reduce the complexity of the application.
If you're already comfortable with ASP.Net, you can deal with complex workflow using existing idioms (Session state, the wizard control, or plain old CLR objects of your own that implement a decision tree/state machine model).
If your problem is really an issue of workflow design, you can integrate ASP.Net apps with something like Windows Workflow Foundation. However, "won't reduce the complexity of the application" probably applies to this, as well; in my limited experience, Windows Workflow Foundation hasn't made building workflows simpler, either.
What you gain by having state all wrapped up in local client objects will most likely be smaller than the cost of learning Silverlight and its idiosyncrasies.
That being said, there's nothing wrong with the idea of attacking this kind of problem in Silverlight. It's just not a silver bullet or anything; Silverlight has its own data access headaches, quirky UI code idiosyncrasies, and requires wrapping your head around yet another model for developing applications.
Silverlight has a Page class that enables you to easily support navigation where you can go back to the previous page as you do in your browser. I think Silverlight pages and the navigation framework is very suitable for the kind of application you have described.
Using Silverlight enables you to create a very rich client experience. Doing that is probably also possible in ASP.NET to some extent, but I find all the moving parts in a traditional web application (HTML, CSS, JavaScript etc.) and their interactions much more complex than the Silverlight model. If you don't have experience using Silverlight you could create a simple page navigation prototype without any real logic to get a feel for the experience. If you are satisfied you could then show it to management to demonstrate the power of Silverlight. If they like eye candy you could change the visual theme of your application in an attempt to impress them. This tactic may backfire, though, if management actually prefers battleship grey.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
What are some of the advantages of using one over the other?
The main advantages of ASP.net MVC are:
Enables the full control over the rendered HTML.
Provides clean separation of concerns(SoC).
Enables Test Driven Development (TDD).
Easy integration with JavaScript frameworks.
Following the design of stateless nature of the web.
RESTful urls that enables SEO.
No ViewState and PostBack events
The main advantage of ASP.net Web Form are:
It provides RAD development
Easy development model for developers those coming from winform development.
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
• Many controls in ASP.NET web forms automatically generate much of the raw HTML you see when an page is rendered. This can cause headaches for developers. With MVC, it lends itself better towards having complete control with 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.
Anyone old enough to remember classic ASP will remember the nightmare of opening a page with code mixed in with html and javascript - even the smallest page was a pain to figure out what the heck it was doing. I could be wrong, and I hope I am, but MVC looks like going back to those bad old days.
When ASP.Net came along it was hailed as the savior, separating code from content and allowing us to have web designers create the html and coders work on the code behind. If we didn't want to use ViewState, we turned it off. If we didn't want to use code behind for some reason, we could place our code inside the html just like classic ASP. If we didn't want to use PostBack we redirected to another page for processing. If we didn't want to use ASP.Net controls we used standard html controls. We could even interrogate the Response object if we didn't want to use ASP.Net runat="server" on our controls.
Now someone in their great wisdom (probably someone who never programmed classic ASP) has decided it's time to go back to the days of mixing code with content and call it "separation of concerns". Sure, you can create cleaner html, but you could with classic ASP. To say "you are not programming correctly if you have too much code inside your view" is like saying "if you wrote well structured and commented code in classic ASP it is far cleaner and better than ASP.NET"
If I wanted to go back to mixing code with content I'd look at developing using PHP which has a far more mature environment for that kind of development. If there are so many problems with ASP.NET then why not fix those issues?
Last but not least the new Razor engine means it is even harder to distinguish between html and code. At least we could look for opening and closing tags i.e. <% and %> in ASP but now the only indication will be the # symbol.
It might be time to move to PHP and wait another 10 years for someone to separate code from content once again.
If you're working with other developers, such as PHP or JSP (and i'm guessing rails) - you're going to have a much easier time converting or collaborating on pages because you wont have all those 'nasty' ASP.NET events and controls everywhere.
The problem with MVC is that even for "experts" it eats up a lot of valuable time and requires lot of effort. Businesses are driven by the basic thing "Quick Solution that works" regardless of technology behind it. WebForms is a RAD technology that saves time and money. Anything that requires more time is not acceptable by businesses.
Proper AJAX, e.g. JSONResults no
partial page postback nonsense.
no viewstate +1
No renaming of the HTML IDs.
Clean HTML = no bloat and having a decent shot at rendering XHTML or standards
compliant pages.
No more generated AXD javascript.
Biggest single advantage for me would be the clear-cut separation between your Model, View, and Controller layers. It helps promote good design from the start.
I have not seen ANY advantages in MVC over ASP.Net. 10 years ago Microsoft came up with UIP (User Interface Process) as the answer to MVC. It was a flop. We did a large project (4 developers, 2 designers, 1 tester) with UIP back then and it was a sheer nightmare.
Don't just jump in to bandwagon for the sake of Hype. All of the advantages listed above are already available in Asp.Net (With more great tweaks [ New features in Asp.Net 4 ] in Asp.Net 4).
If your development team or a single developer families with Asp.Net just stick to it and make beautiful products quickly to satisfy your clients (who pays for your work hours). MVC will eat up your valuable time and produce the same results as Asp.Net :-)
Francis Shanahan,
Why do you call partial postback as "nonsense"? This is the core feature of Ajax and has been utilized very well in Atlas framework and wonderful third party controls like Telerik
I agree to your point regarding the viewstate. But if developers are careful to disable viewstate, this can greatly reduce the size of the HTML which is rendered thus the page becomes light weight.
Only HTML Server controls are renamed in ASP.NET Web Form model and not pure html controls. Whatever it may be, why are you so worried if the renaming is done? I know you want to deal with lot of javascript events on the client side but if you design your web pages smartly, you can definitely get all the id's you want
Even ASP.NET Web Forms meets XHTML Standards and I don't see any bloating. This is not a justification of why we need an MVC pattern
Again, why are you bothered with AXD Javascript? Why does it hurts you? This is not a valid justification again
So far, i am a fan of developing applications using classic ASP.NET Web forms. For eg: If you want to bind a dropdownlist or a gridview, you need a maximum of 30 minutes and not more than 20 lines of code (minimal of course). But in case of MVC, talk to the developers how pain it is.
The biggest downside of MVC is we are going back to the days of ASP. Remember the spaghetti code of mixing up Server code and HTML??? Oh my god, try to read an MVC aspx page mixed with javascript, HTML, JQuery, CSS, Server tags and what not....Any body can answer this question?
Web forms also gain from greater maturity and support from third party control providers like Telerik.
In webforms you could also render almost whole html by hand, except few tags like viewstate, eventvalidation and similar, which can be removed with PageAdapters. Nobody force you to use GridView or some other server side control that has bad html rendering output.
I would say that biggest advantage of MVC is SPEED!
Next is forced separation of concern. But it doesn't forbid you to put whole BL and DAL logic inside Controller/Action! It's just separation of view, which can be done also in webforms (MVP pattern for example). A lot of things that people mentions for mvc can be done in webforms, but with some additional effort.
Main difference is that request comes to controller, not view, and those two layers are separated, not connected via partial class like in webforms (aspx + code behind)
My 2 cents:
ASP.net forms is great for Rapid application Development and adding business value quickly. I still use it for most intranet applications.
MVC is great for Search Engine Optimization as you control the URL and the HTML to a greater extent
MVC generally produces a much leaner page - no viewstate and cleaner HTML = quick loading times
MVC easy to cache portions of the page.
-MVC is fun to write :- personal opinion ;-)
MVC lets you have more than one form on a page, A small feature I know but it is handy!
Also the MVC pattern I feel make the code easier to maintain, esp. when you revisiting it after a few months.
MVC Controller:
[HttpGet]
public ActionResult DetailList(ImportDetailSearchModel model)
{
Data.ImportDataAccess ida = new Data.ImportDataAccess();
List<Data.ImportDetailData> data = ida.GetImportDetails(model.FileId, model.FailuresOnly);
return PartialView("ImportSummaryDetailPartial", data);
}
MVC View:
<table class="sortable">
<thead>
<tr><th>Unique Id</th><th class="left">Error Type</th><th class="left">Field</th><th class="left">Message</th><th class="left">State</th></tr>
</thead>
<tbody>
#foreach (Data.ImportDetailData detail in Model)
{
<tr><th>#detail.UniqueID</th><th class="left">#detail.ErrorType</th><th class="left">#detail.FieldName</th><th class="left">#detail.Message</th><th class="left">#detail.ItemState</th></tr>
}
</tbody></table>
How hard is that? No ViewState, No BS Page life-cycle...Just pure efficient code.
I can see the only two advantages for smaller sites being:
6) RESTful urls that enables SEO.
7) No ViewState and PostBack events (and greater performance in general)
Testing for small sites is not an issue, neither are the design advantages when a site is coded properly anyway, MVC in many ways obfuscates and makes changes harder to make. I'm still deciding whether these advantages are worth it.
I can clearly see the advantage of MVC in larger multi-developer sites.
Main benefit i find is it forces the project into a more testable strcuture.
This can pretty easily be done with webforms as well (MVP pattern), but requires the developer to have an understanding of this, many dont.
Webforms and MVC are both viable tools, both excel in different areas.
I personally use web forms as we primarily develop B2B/ LOB apps.
But we always do it with an MVP pattern with wich we can achieve 95+% code coverage for our unit tests.
This also alows us to automate testing on properties of webcontrols
property value is exposed through the view eg
bool IMyView.IsAdminSectionVisible{
get{return pnlAdmin.Visible;}
get{pnlAdmin.Visible=value;}
}
)
I dont think this level of testing is as easily achived in MVC, without poluting my model.
You don't feel bad about using 'non post-back controls' anymore - and figuring how to smush them into a traditional asp.net environment.
This means that modern (free to use) javascript controls such this or this or this can all be used without that trying to fit a round peg in a square hole feel.
Modern javascript controls as well as JSON requests can be handled much easily using MVC. There we can use a lot of other mechanisms to post data from one action to another action. That's why we prefer MVC over web forms. Also we can build light weight pages.
My personal opinion is that,
Biggest dis-advantage to using ASP.Net MVC is that CODE BLOCKS mixed with HTML...
html hell for the developers who maintain it...