What were typical problems during developing on ASP.NET? So, would you like to describe typical problems/mistakes during developing on ASP.NET from your experience?
UPD
I have been working as ASP.NET developer for 2 monthes.
The biggest mistake in my opinion is that many people do not take the time to learn and understand the framework before they begin coding. This often leads to solutions that do not follow the intentions/paradigm of the framework.
My biggest issue was the page lifecycle. When you start adding Masterpages & user controls, it gets a bit tricker figuring out what happens and in what order
When you say ASP.NET I'm assuming you mean WebForms.
The biggest problems are related to DataBinding, event handling, viewstate and control id's. These concepts are entangled in complex ways that start to break down whenever you take even a single step outside the beaten paths.
WebForms was built to provide a similar experience to web development as to desktop UI development. After years of ASP.NET WebForms development experience I think I can safely say that WinForms does not live up to the promise. The attempt to hide web specific concepts (like the fact that HTTP is stateless) means that you as developer loose a lot of control, which makes it hard to figure out what the problem is when something does not work as you'd expect.
For anyone starting .NET-based web development I suggest you get intimate with more modern web development platforms like the ASP.NET MVC or MonoRail. The initial learning curve may be a bit steeper but when you get rolling you'll be much more productive.
Most of the asp.net web forms problem has been overcome by asp.net mvc framework. The problem in web forms were many. The biggest i feel is it has only one form. others are misuse of viewstate, which later overcome by control state. Web form has complex page life cycle specially if you are dynamically adding user controls etc.
On the other hand i see no problem in asp.net mvc framework.
I think most common mistakes on developing not only in Asp.net is that when you try to study something or just a part of it and feel like you need to stop because you think you know everything which is obviously wrong. For me Asp.net is like the world because when you know the continent of Asia,Europe,etc. it doesn't mean that you need to stop because you already know a lot of things. I think it's not that way because Asp.net have so many capabilities that every developer can explore like me who is also still studying and when you learn something, like me most of the time I say hey I never thought this exist in the map of Asp.net and again I say hey you know what I learn something new, I wonder if my previous project applies to what I learn today. Things like that, I learn in every step and the ladder never ends.
I think making a statement about your background/experience and knowledge of Http, Html etc. might help people give a better, more meaningful response.
Typical problem #1: Master pages. Coming from classic ASP, this concept was new to me so I learned how to use it properly in "the hard way". In the beginning I tried to change things defined in the master page from within content pages which is obviously wrong.
Typical problem #2: User Controls. The classic ASP does have "include" mechanism allowing the programmer to put repetitive blocks of code so I was familiar with the basic concept, but combining it with existing Page, learning the different life cycle and understanding the real power of the custom controls took long time and many bumps on the road.
From my point of view,the biggest problem in considered to the state management.
The people often get confused what to use on a particular situation.
Next one is most of don't know about the page life cycle well.which is most important during custom controls and all.
And the most important thing is new comers often don't know how to actually indulge oops concepts while software development..
Related
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
What’s your choice for your next ASP.NET project: WebForms or MVC?
Can you list some reasons that would make you use ASP.NET webforms for a new project, instead of MVC? I've heard a lot about the opposite, but not things that are done easier or better with webforms. I'm not talking about developer preferences here, but rather technology features and how they map to project features.
The only argument for WebForms is the need to design highly complex (read cluttered) interfaces with a whole lot of interconnected elements which in all or in part should react to changes in other elements.
A typical example would be some enterprise application (from SAP or smaller vendors). They usually have interfaces bordering madness. You'd have a hard time trying to synchronize the controls manually with JavaScript if you were on MVC. With WebForms it's by far easier.
Whether it is a good idea to build such interfaces is another matter entirely.
In WebForms element events trigger a page postback. They go to the same url and are processed in a unified manner. This is what makes the architecture very scalable.
With MVC to accomplish this you would have to set up a bunch of service urls to handle posts from different controls, then process those posts and update view models accordingly. This all involves a lot of trickery and juggling. Not that it is not doable - it is, but not on a big scale. This approach would not be scalable. Sooner or later you will arrive at the understanding you'd need to build your own framework in the direction of stateful object-oriented HTML/HTTP abstraction like WebForms.
A few things that could push me (back) towards WebForms:
I need to produce something that can be taken over by someone who isn't primarily a web application developer (say a WinForms programmer), and the app could substantially be maintained through Visual Studio's Forms Designer. The IDE support makes the development model closer to that of WinForms.
An app that needs to look Ajax-y but will be maintained by someone who won't learn JavaScript. I think things like the UpdatePanel (while horrible in so many ways) are actually pretty good for that scenario.
Possibly for some kind of demoware, again because of the IDE and ASP.NET AJAX. Fairly quick to knock up some reasonably smart screens without too much thinking.
I need a powerful CMS and need to stay within .NET. At this point it looks like there's better choice in WebForms than in MVC (though hopefully that's changing).
I'm working with a team who are already familiar with it and aren't going to learn MVC.
Of those, probably the CMS is the requirement I could think of right now that would actually make me use WebForms.
If you only know webforms MVC comes with a learning curve so you will need to spend quite some time training (or risk making serious security or performance errors)
You need a tiny little app NOW It probably is quicker to build a throw away mock application in webforms if you go for the anti-pattern. E.g. SqlDataSource, Logic in your code behinds etc.
Rich controls GridView is an excellent control, having sorting etc all built in for you with little code needed as long as your custom requirements are small.
Lack of web development experience Web forms is just easier. It takes more concerns off your plate. Much better for a newbie as its tough to go wrong.
Having said that, if you know what you are doing or have the time to learn and you want to build a long lasting site, MVC is soooo good. And more fun too.
I'll add that there is nothing really wrong with web forms. It's perfectly possible to build high performance app with it. It's just times have changed since it first came out and MVC has addressed those changes well.
Personally, i find MVC very good for admin-pages. because they usually have a load of tables, and are made for data input and editing. MVC is 'made' for those things, so it's going very fast making those pages.
webforms I use for more complex things, like the User-end of the site. the site i make shows courses people can take. the registering for a course is a 5 step procedure, which in MVC, I have no real idea how to do it. I'm sure it can be done in MVC but I think it's better/faster in webforms.
however in the end I do like MVC more. It feels so much cleaner to work with.
The only time i would consider going with Web Forms in a new project is if there was a component created for Web Forms that solved a specific problem that would be much harder to solve using MVC.
I can no longer see any advantage of Webforms over MVC, apart from some upskilling effort which should not be prohibitive.
[Originally I believe MVC wasn't compatible with webcontrols, so wishing to use Dundas chart control for example wasn't possible. That would have been a good argument for using webforms depending upon your requirements. But I believe this is no longer the case, and anyhow, you can include webforms in your MVC project as a worst case.]
It depends!
The difference between WebForms and MVC is if you can TDD and control the complete markup.
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 ask this not to start anything negative. Rather, after looking at ASP.NET MVC it hit me (duh) that I am not using controls like on webforms but coding html markup by hand (gasp.)
Is this a move backwards? I remember coming from classic asp to asp.net and dragging and dropping controls, creating a bll, etc. now it seems I am doing all that by hand, again, like classic, except I have good mvc design.
I guess I'm trying to figure out why this is a move forwards from what was a rapid development environment to what appears to be more tedious.
EDIT:
I always thought Visual Studio .NET was one huge reason to go with ASP.NET with all its controls and automation. Now with MVC it is makes me think it's just like any other MVC with a decent IDE, since I'm doing everything by hand now.
"Classic" ASP.NET hasn't gone anywhere - you can still use it if that's what you want or need
Though you may or may not get "drag-and-drop" functionality, between AutoComplete and the various render helpers you can easily get a working view in minutes
Creating the views is only a small fraction of the overall project
Even in ASP.NET I rarely used the visual editor. I always felt that it got in my way and made decisions for me, wrongly.
Is a step forward:
the code is fully testable
you gain full control of what the server is generating
no more viewstate!
increased server response speed
less server cpu load without the WebForm's Page lifecicle
a programming model which is more close to the web (webforms aimed to bring to the web the desktop programming model).
....
Funny you should mention this - I just finished reading a chapter in "Professional ASP.NET MVC 1.0" that answers this exact question.
The book they compare the difference between Web Forms and MVC as the difference between leading an orchestra and composing a song. MVC doesn't give you the same level of immediate response as web forms, however it does give you a level of granularity a lot of web developers have come to expect. It's well known that ASP.NET controls, even in their later versions, inject more HTML than is desired.
So, functionally yes it's a step back, but only because you've been given complete control over what gets put on the page. As always, pick the right language for the job.
It's a step sideways, rather than forwards or backwards; just another way of doing the same thing, with a different emphasis. With ASP.NET forms, it's easy to "draw" the page so it looks roughly like you want it to look, but it's hard to make it behave like a proper web application. With ASP.NET MVC, it's not as easy to throw together the appearance of it, but it's actually easier to make it behave like a website, with URLs that describe the content being returned in a predictable way.
Tell me about it. I'm still trying to work out why I'm subjecting myself to this. Ultimately the number #1 sell is Unit Testing. For those of us who don't subscribe to this, the advantages are few, if any, IMHO.
That said, I'm open to be convinced otherwise. I think that MVC is a good foundation, but like you say, it's very very tedious at times. The RAD system of drag/drop controls from the toolbox used to be terrible, but since vs2008 it's been quite a pleasure. I expect the major toolkit vendors like Telerik, Infragistics, ComponentOne et al will soon ship MVC friendly toolkits (I hope!).
I'm only learning it because I'm currently on a project that was built on it (not my design). Don't forget though that YOU DONT HAVE TO USE IT. Classic ASP.NET didn't disappear. :)
-Oisin
For me, getting rid of viewstate and the page life-cycle has been an addition by subtraction. :) Not to mention a boon to my knowledge of web programming because of having to get my hands "dirty".
Some people might say that ASP.Net was a step backwards in that it can constrain the flexibility of the application by locking you into using pre-built controls.
Classic ASP was immature, but it did give you very fine-grain control over the mark-up code, which many find is lacking in vanilla ASP.Net.
As I see it the ASP.Net MVC paradigm gives the developer closer control over mark-up, while still giving access to all of the advantages of the .Net framework.
I think it was a necessary step backwards, or better yet backtracking a few steps to move ahead.
The web had evolved in a direction that diverged significantly from ASP.NET's core design premise.
In the end, comparing ASP.NET to other agile web frameworks, I believe it was a case of "you can't get there from here".
I thought part of the point of the ASP.Net MVC Framework was giving the developer more control over the HTML. Something the drag-and-drop controls make a mess of.
ASP.net MVC is not for everyone or for every application (some may argue this through!). MVC is a framework you can use in its basic form or extend to your hearts content. It allows you full control over what is rendered to the user.
MVC has a number of advantages:
Seperation of concerns resulting in better testability, arguably better design and easier to modify UI
Full control over what is rendered - which can result in standards compliant, smaller, faster pages
Clearn SEO friendly URLs although ASP.net 4 has routing features
In its purest form without use of session load balances very well.
It also has some disadvantages:
Learning curve and change of thinking required
Lack of 3rd party support although this will change
Pages can look cluttered
Can be more difficult to develop certain types of controls e.g. something like a reorderable data grid or something with many steps like a wizard
I think it's a step in the right direction, but it's nowhere near as mature as WebForms. I expect to see commercial 'control' libraries before long, although it won't be drag and drop stuff.
Also, if you're using WebForms for your view engine you're missing the point, in my opinion.
One of the biggest differences is the page life cycle. This is for me the main paradigm change. Many other benefits could be addressed following good practices, although ASP.NET did not enforce them.
If you are used to WebForms and ASP.NET, MVC may seem awkward, but if you come from classic ASP, PHP, Rails o any other environment that respects the nature of the HTTP flow, its a good option. You get the benefits of a great IDE such as Visual Studio, a complete and powerful framework such as .NET (whether you use C# or VB.NET) and everything works in a more or less familiar way.
You may lose ASP.NET controls and visual designer but for many people that was more an annoyance than a benefit, depending on the type of applications you were building and your previous experience. ASP.NET was a nice transition from Winforms but for people who always worked on a web environment seemed a bit "forced".
Didn't Scott Hanselman at one point say that "MVC isn't Web Forms 4.0"? I've taken from that, that he means that MVC isn't to replace ASP .Net at all, and it is simply another option to Win Forms and Web Forms.
I do agree in that when I first started looking at MVC, I was much more reminded about classic ASP (not the .Net version) in the way that there's no code behind page, and there's more <%= whatever %> markup in the views, which threw me for a little while, as when I used ASP .Net for the first time, it was as though ASP .Net discouraged the need for such markup.
Personally, I like MVC; I think it's great, but there's a little room too for ASP .Net..!
I’m new to .net, though I’ve been writing in classic asp for years. I know it’s time to make the change, but I can’t stand how bloated the HTML becomes.
For example, a simple menu using a web.sitemap and adds over 100 lines of JavaScript and HTML. A simple form with server-side validation adds in masses of ugly JavaScript. And a basic table of data using GridView adds in a ViewState that makes my eyes water.
Call me a purest, though I don’t like sending data to the browser unless it’s needed. And I don’t need a form-riddled menu when a simple unordered list of links will suffice.
So, set in my ways, am I destined to forgo the benefits of the Framework entirely by insisting on writing my own, cleaner code for everything? Or am I missing the point?
As a brief aside I’m a big fan of Campaign Monitor, a newsletter distribution company. They’ve written an elegant and comprehensive user-interface in .net without a single ViewState or bizarre .net-mangeled ID reference. Even the Sign Up form on their website (/signup.aspx) is as clean as a whistle. What’s their secret?
I hope I not the only one. Any advice would be greatly appreciated.
Try ASP.NET MVC or one of the other MVC web frameworks for .NET
If your GridView doesn't need it, then turn ViewState off for it.
Also, please edit your question to say what version of .NET you're using. Some of this gets better, and some does not. You might also want to try VS2010 beta 1, and complain about anything it doesn't fix.
Another idea would be to go on treating ASP.NET like it's classic ASP. Do it exactly the way you're used to, but do it with the idea in mind that there's about 10 years of development work that's gone into solving some of the problems of classic ASP. Once you actually hit one of those problems, find out if ASP.NET has solved it, and how.
For instance, I have a hard time believing you enjoy writing FOR loops to generate table rows. If you get tired of that, learn to use a Repeater control, or a DataList control, or even the old DataGrid control. If you turn ViewState off on those, I think you may find the generated HTML to be acceptable, and you'll find it a lot easier to generate tables and other structures that repeat based on repeating data.
You can opt-out of much of that bloat by not using all the out-of-the-box controls that come with it but I prefer the MVC route that activa suggested
Here is my list:
Keep the use of asp controls to minimum
Turn off Viewstate when it's not need
If you don't want the JavaScript associated with Client Side Validation (with ASP.NET Validation) set the EnableClientScript to False
Use asp:literal instead of asp:Label
Yeah it seems to be that everyone is bashing webforms at the minute for the reasons you have outlined above. HTML heavy Controls, ViewState, no control over ClientIDs all seem to cause an issue with people.
However let is be said that you can use asp.net (webforms) and produce some decent applications.
Control of html is yours through httpModules and httpHandlers and some of the issues mentioned above are fixed in asp.net 4.0
I just listened to a great podcast comparing MVC and webforms. Its in the area you are asking about. Also check out this blogpost by a dotNetNuke regarding the good asp.net code and why people should take a breath before converting everything to mvc.
Having said that I've tried Asp.net MVC and it is awesome. I'd probably look at dotNetNukes code to as its a mature asp.net product.
Also, when you do want to use these newfangled server controls, check out the css friendly control adapters. They clean up much of the bloat.
For client IDs the key thing to remember is to let the framework handle them. If you need to get an element on the client side, remember to emit the control's ClientID property into your script.
I've been using a template system and am very happy with it. Basically write an http handler for .html files and put tokens in the html files that regex could find in one sweep and inject any stuff. (google template c# for more info).
I tried some of the supposedly cool new features of ASP.NET for a little while. I also didn't like most of them. I felt constrained to work within the limitations of the common paradigms Microsoft had dreamed, even though I new how easy it would be to produce the HTML and JavaScript myself to do specifically what I wanted to do without having to learn how to jump through the hoops of so many new Microsoft-specific idiosyncrasies.
Anyway, I stopped using the parts of ASP.NET I didn't like on new code I've been writing lately. When I first started using ASP.NET, nothing in the MSDN documentation jumped out at me about how to avoid such complications, so I posted a couple "Hello, World" at http://www.agalltyr.com/rawaspdotnet.html to help spread the heretical word. I couldn't care less if it's the latest cool technology or the recommended technique. It's a reliable and reasonably efficient tool I can use to do my work.
Oh, and I'm not in the mood to learn ASP.NET MVC either. That's just more idiosyncrasies. Give me a language (C#) and a framework (.NET), and I'll design my own abstraction, thank you.
There are lots of articles and discussions about the differences between ASP.NET WebForms and ASP.NET MVC that compare the relative merits of the two frameworks.
I have a different question for anyone who has experience using WebForms that has since moved to MVC:
What is the number one thing that WebForms had, that MVC doesn't, that you really miss?
Edit
No-one has mentioned the WebForms validation controls. I am now working on some code that has a few dependant validation rules and implementing client-side validation for these is proving slow.
As a PHP/Classic ASP person, I ventured into webforms world about 5 years ago. After having to handcode things like table grids, calendars, etc, in scripting languages, it seemed like webforms would be a tremendous helping-hand. It was...that is until you need even a slight bit of customization beyond alternating row colors and the like. Yeah, you could have a gridview running with a few drag-and-drop motions. But customizing even what would seem like a simple thing could turn into hours of torture and research.
I also think a lot of the examples given in .NET online are oversimplified for the effect of making webforms look "easy". Sure you can get that gridview to show only 10 records of a 100,000 record table, but do you realize that ALL of the records are being loaded into memory by default? As an example of the over-complicatedness of rectifying that problem, I spent a while creating a pageable gridview that only loads chunks of records, but it wouldn't work. After an hour of research, I found that you had to delete an extra property that the IDE inserts into the codebehind. Not fun when stupid stuff like that sets you behind.
And at every turn, it happens.
Don't even get me started on viewstate.
But then the clouds parted, and .NET MVC was handed to us. Now THAT is a framework. If you are a web developer, you should know whats happening when someone makes a request to your webserver. The abstraction and layer of cruft that webforms put on top of that is a disservice.
For the most part, I'm able to develop applications at the speed of PHP scripting and FINALLY have TOTAL control over the UI. That's what it's all about.
And as an additional note: People need to stop complaining that they are creating "tag soup" in MVC views when they find they have to use <%= %> tags and the like. Drag and drop your gridview onto the page, set all the properties, then view the crap it gives you. And your not nearly done yet, now you have to attach events and put more gridview-related code in your codefile. Talk about messing up the coding experience. I'll take a simple foreach loop anyday.
nothing :)
I really like the way ASP.NET MVC works. I want to control my HTML. I don't need controls. We can get the same functionality with HTML helpers and third party tools, e.g. jQuery and all the available plugins.
Here's an example on how to use a gridview-like with jQuery grid on ASP.NET MVC.
Although Ruby on Rails is a more mature framework, I do think that ASP.NET MVC is on the right track.
I miss the gridview, the simplicity of getting built in sorting and paging in with very little effort. I use grid functionality all the time and have still not found a good alternative in mvc
Well I do miss something :
the ability to have a pageable grid in seconds.
Although it wouldn't be very fair since I also had to create a class to feed to the ObjectDataSource to have an efficient pagination. And also the pagination would work only with the JavaScript on or I would have to write code to read the QueryString (for ex. &pag=2 etc.) and so on.
In fact... I guess there isn't much too miss.
The simplicity of having only one form on a page. I think the html form functionality is kind of awkward and not very intuitive and I guess there is a good reason why the webforms creators tried to abstract away form handling in webforms.
One difference, which I am sure will be rectified over time, is the expansive amount of reference material and examples online for web forms versus the relatively sparse amount for MVC. However, one could argue that a lot of the material on web forms covers topics such as the page life cycle which MVC no longer makes necessary (thank goodness).
Until now nothing really.
I definitely miss MVC every day at work while I look at the ugly WebForms code I want to wipe it all out and now make everything transparent, clean and beautiful.
Of course only time will show whether the new girl is really better than your old wife.
As crazy as it sounds, I miss the calendar control. Not for datepickers or that sort of thing, but for scheduling apps where you want to show a full page month-at-a-glance/outlook style events calendar with selectable or clickable links that you inject via the day render event.
If anyone knows of an MVC alternative, please share! Rolling your own in this case is doable, but kind of a pain.
Viewstate is the thing i miss - until i remember problems it causes.
Then i bend my mind and look for another approaches (smarter model binding, ajax etc.) which usually turns out to be better (but slower to find & implement).
The main thing I miss is the documentation. WebForms, because of it's relative maturity, has a lot of official documentation and also a lot of 3rd party examples and snippets available. However, this is improving all the item and, as MVC gains momentum, I hope it will be on a par.
Nothing as well.
WebForms do so much automatically but frequently I had to hack it to suit my needs.
MVC let me do what I want and I can hack it to get things done better/faster.
I love to control the output and prefer clean, lightweight style.
Output Caching is not really implemented in ASP.NET MVC (as of version 2). There are tricks to get it working, like using Web Controls with the OutputCache directive, or using WriteSubstitution, but all these tricks go against the nature of MVC in some way. Output Caching for anything other than entire action methods is really tricky to get working in ASP.NET MVC, and always induces enormous technical debt. Since Output Caching, especially in the newer versions of IIS, is incredibly performant compared to data layer caching, this is a shame.
simplicity in Dragging and dropping controls.
might be seeing some of this in the near future maybe in mvc4
Reference :- http://www.codeproject.com/Articles/808297/Things-you-will-miss-in-ASP-NET-MVC-as-an-ASP-NET
I will not say i miss because all the changes are happening for good. But yes i would miss the below
The lovely server controls who just give output in a blink.
The behind code file.Double clicking and going to the Code behind for some reason made me superior.
Viewstate magic.
Now i need to get in to headache of POST and GET.