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..!
Related
I'm a new comer to the asp.net world. I hear a lot about asp.net mvc and it's advantage over webforms about the ability to customize the markup and css. I also heard that asp.net is much easier to learn than asp.net mvc so I decided to go for asp.net and webforms. My question is: what's the level of customization a web developer/designer can get with webforms concerning the markup and css?
You can have as much customisation as you like in the html output! You can customise everything in web forms. However, with customisation brings time, effort and room for error. All of these things is what web forms is trying to save you.
However, since you are just starting out I wouldn't worry. Just make your web forms how you want and forget the customisation of output (it is much better with ASP.NET 4 anyway). In a few years when you are more experienced then worry.
If you were going to customise everything then you should have gone with ASP.NET MVC - it is one of its main arguments. But there is nothing wrong with web forms. Particularly if you are beginning with asp.net in general I'd say it is better.
Standard ASP.NET WebForms uses server controls that generate the markup for you, so the level of customization is limited to what the controls you are using provide. There are techniques that allow you to override what is rendered by the controls and thus customize the markup and also write your own controls but it requires some coding. It is possible to achieve almost complete customization of the markup but it IMHO requires more efforts than a web developer should need to put into something like this.
While it is definitely possible to have a SEO friendly, unit-testable, maintanable, standards compliant application using classic ASP.NET WebForms, the efforts it requires will be significant compared to ASP.NET MVC. But if you don't care about those things you will be able to pretty quickly develop web applications.
ASP.NET comes with a set of built in user controls - things like text areas, buttons etc. These mimic winforms in how they are supposed to work (events etc), however this is a rather leaky abstraction (you must always remember you are working with HTML and HTTP).
The user controls allow reuse and when a page is built they emit HTML - you have little control over the emitted HTML (unless you override the rendering, which kinda defeats the point), hence the perception that they are harder to customize. It is not easy to get right either and requires more work than I think is worth.
There are also different compromises in the way pages are rendered out (ids for example end up as a long string of concatenated container control names) which make MVC a better choice if you are looking for control over your HTML.
Microsoft suggests that you pick the technology based on your needs:
While ASP.NET offers rich controls and produces quick results without great control over the markup (as mentioned: it can be done but somehow beats the idea behind ASP.NET and creates a lot of additional code), it suffers from the flaws mentioned by the other posters.
In MVC, there is a limited set of "out-of-the-box" controls and you'll have to code more on your own (including clientside JavaScript) but you do have more control over the rendered markup of your controls. In addition to that, your project will generally have a clean separation of concerns which benefits (unit) testing and maintainance.
Another aspect that hasn't been mentioned yet: In ASP.NET a page undergoes the so-called "ASP.NET Lifecycle" every time the client communicates with the server. The Lifecycle consists of several events that are fired in a special (and sometimes confusing) order. Handling those event in the right order in complex web applications is one of the biggest difficulties in ASP.NET and often leads beginners to forfeit. In MVC you don't have to deal with that kind of problem.
Therefore I strongly recommend that you take a look at the ASP.NET architecture before you start to code. Here is a very basic start: http://www.asp.net/learn/videos/video-6558.aspx
Personally, I started with WebForms and am now moving to MVC after I worked with the similar MVVM pattern in Silverlight and WPF for my bachelor thesis. This kind of did it for me so that I now understand the benefits and ideas behind MVC a lot better. Once you are used to WebForms, switching won't be that easy though.
I know this question has been asked before and I read all the answers but they still don't give me the answers I am looking for. I need something concrete. I volunteered to give a presentation on MVC to other developers in our group which forces me to learn it. The big question everyone has is: "What can MVC bring to the table that we can't do in asp.net or MVC can do faster. I have just gone through Nerd Dinner and actually created a complete website that sort of mimics Nerd Dinner. But as great a job that Scott Guthrie did on it, there are big gaps that aren't answered such as, how do I throw a textbox on the listing page with a button and do a simple search. In asp.net, I would throw a textbox, button and grid on the page and bind it to a sproc and away I go. What is the equivalent in MVC. I guess I need a really good tutorial on how to use MVC without using Linq-to-Sql.
I know I am sort of babbling on about this but it is a very serious question that still seems to go unanswered.
On a side note, the View page of MVC brings back nightmares of classic asp with all the in-line code that we got away from way back when with code behind pages. Yes, MVC has Controller and Model classes which are great but I still don't like the classic asp tags in the html.
Help me out here, I really like the concept of MVC and want it to be successful but I need more!
how do I throw a textbox on the listing page with a button and do a simple search. In asp.net, I would throw a textbox, button and grid on the page and bind it to a sproc and away I go
That's exactly the biggest problem behind "classic" ASP.NET aka WebForms.
You shouldn't be thinking in terms of pages, buttons and events.
You should learn the basics of how web works. Then you'd understand that the web speaks in terms of HTTP protocol, its commands GET, POST and others. Presentation is HTML, CSS and the Document Object Model which is where JavaScript comes into play. And there are in fact no pages, an url is just a pointer to a resource which is not necessarily mapped to a physical file (.html or .aspx) on the server.
the View page of MVC brings back nightmares of classic asp with all the in-line code that we got away from way back when with code behind pages.
I also came to MVC after staying with WebForms and I discovered I like the inline code very much. It makes the view structure very clear, which cannot be said about the coupling of static markup (aspx) + manipulating server controls in code-behind. The latter is actually a nightmare - your code is generating the markup output but you don't see where and how.
What can MVC bring to the table that we can't do in asp.net or MVC can do faster
It removes the ugly stateful abstraction which WebForms gave us. You're now back where it started. What you have now is:
Option to separate your presentation part (views) from your application logic. Before there was all mixed together, code-behind talking to the database, calling other services, modifying the markup. It was mess. It resulted in lots of serious applications written but hardly maintainable any more.
Ability to automatically test your application logic. With WebForms and code-behind, how would you invoke a certain scenario? You'd use tools like Selenium to mimic user activities. Now, when your views are just a passive presentation layer, you don't have this problem any more. You test your business logic and model output very easily. Views are there to display the results. If the model got the correct data in a particular scenario, the view will display it correctly. If not then not. Period. No need to test views.
Control over your markup. That is if you care. If you a former Windows developer who doesn't give a damn about HTML documents being valid, being semantically correct and optimized for web engines, then it's of no use to you. I mean, "pages" are sort of displayed, user clicks are processed like in desktop application, what else, right? But if you were interested in all those things, then you'd look at the final markup output and see that it is ugly, with lots of errors, limitations which you simply can't fix. Because it's how controls, buttons, data grids etc. display themselves. An attempt to fix them would require to override markup generation of those controls which is a heavy task. Why don't just drop it and do everything manually?
What MVC takes from the table?
A server-side processing of "control" "events", like in Windows programming. If you're developing a desktop-like application for web medium, like those typical "business" software with dozens and hundreds of controls to drive you crazy, then MVC will drive you crazy, because you will have to wire each single control individually with JavaScript.
But if you're not developing those kinds of applications (which require certain mental abilities to work with), but developing modern usable software for web, then WebForms would drive you crazy. Sooner or later.
I was also learning MVC in the past few days. My experience is that is provides a much less complicated model of the web.
While WebForms promised that it will make web development very close to Windows development with a complicated event model, controls, and all the stuff.
Why? Because at the time Microsoft's developer base was mostly VB and C++ developers who were thinking in terms of forms, controls, and this provided an easy way for them to begin developing for the web.
What MVC provides is more control over the underlying protocol and more control over the HTML you output.
Plus, they give you ASP.NET routing built-in, so your URLs will also look and feel much better.
An example: StackOverflow was built using ASP.NET MVC.
Your example:
how do I throw a textbox on the
listing page with a button and do a
simple search. In asp.net, I would
throw a textbox, button and grid on
the page and bind it to a sproc and
away I go.
You create an Action for it in the current Controller, throw a form on the page with Html.BeginForm which points to that action (remember, with MVC, you can have multiple forms on pages), throw a textbox and a submit button in it.
Then, according to your taste, you can either create a separate view for the search results, or reuse the existing view. The new action can be named the same as the old one, with [HttpPost] on it (or [HttpGet] if you prefer that), so the URL won't confuse the users more. You can then call your SPROC in your action and you are good to go.
(All this accomplishable in a matter of minutes.)
The other thing I like about MVC is that it is basically VERY EASY to create CRUD operations with it. (Like NerdDinner.)
VS generates 80% of the code required for your views, which then you can customise very easily.
I recommend you reading the whole book and not only the NerdDinner free episode, it gives you a very good picture about the technology.
The bulky Behind code is one the biggest issue with Webform. The RAD approach is good to create project faster but the growing bulky behind code is not maintainable , reusable and testable. There are 5 problems which MVC resolves of WebForm.
Problem 1 :- Webform was a View based solution for Action based requirement
Problem 2:- Tight coupling between behind code and view
Problem 3:- HTML is not the only response type in Webform it was not flexible
Problem 4:- Flexible Combination of view and data not possible with webforms
Problem 5:- Behind code was a heavy bulky class which can not be instantiated.
All the above points has been explained in this codeproject article http://www.codeproject.com/Articles/821275/Why-ASP-NET-MVC-ASP-NET-MVC-vs-ASP-NET-webforms
The following article got me started with MVC
ASP.NET web forms aren't going
anywhere. As much as I love ASP.NET
MVC, it is not the end-all-be-all
one-size-fits-all solution to web
development. Both of these approaches
have their rightful place in a web
developer's toolbox and it's important
to recognize their strengths and
weaknesses. In general, the ASP.NET
MVC framework tends to sacrafice
ease-of-use (e.g. viewstate,
validation, etc.) in order give
developers tighter control over the
reins. This can be a great thing, but
only if you take advantage of it.
Otherwise it can just as easily be a
hindrance.
With that in mind, I have developed a
quick metric to determine if ASP.NET
MVC is right for you. The way I see
it, there are three primary reasons a
developer should choose the ASP.NET
MVC framework over ASP.NET web forms.
If none of these reasons are
compelling to you, then you should
stick with ASP.NET web forms:
To Unit Test This, in my opinion, is
the most compelling reason to use
ASP.NET MVC. When it comes to unit
testing, ASP.NET MVC simply blows
ASP.NET web forms out of the water.
It's not even close. Whereas ASP.NET
web forms requires you to jump through
all sorts of hoops to test around the
page event lifecycle, the ASP.NET MVC
framework practically begs to be
tested. There are interfaces
everywhere screaming "mock me!".
There's a reason why the biggest
ASP.NET MVC supporters also tend to be
TDD proponents; it's because ASP.NET
MVC actually allows for TDD.
Personally, I think this is where all
the zeal comes from. Simply put: it's
really, really hard to do TDD with
ASP.NET web forms and really, really
easy to do it in ASP.NET MVC.
To Gain Control and Extensibility As
pointed out in the comments, ASP.NET
MVC gives you more control and
extensibility options than ASP.NET web
forms. You get complete control over
the page request lifecycle and the
ability to substitute out several key
pieces of the framework (e.g. view
engine, routing, etc.), none of which
is possible with ASP.NET web forms.
In addition to this, you also gain
full control over the rendered HTML.
In general, the rendered HTML from
ASP.NET web forms applications is
atrocious. The web controls it
utilizes generate garbage ids and
hidden fields galore that not only
hamper the performance of a site, but
also make CSS styling and Javascript
development a pain. ASP.NET MVC
forces you to be more in tune with
your HTML. There aren't any repeaters
or datagrids that magically generate
markup for you. There aren't any
hidden fields to persist state for
you. It's just you, the HTML, and a
few extension methods (which you don't
even have to use).
To Learn Something New In other words,
"because you feel like it". This was
actually why I started using ASP.NET
MVC. It never hurts to look at how
you're approaching development from
another angle.
I should also point out that learning
ASP.NET MVC is incredibly engaging
process since the ASP.NET MVC
framework team has been so interactive
in the process. I think a large part
of the appeal of ASP.NET MVC is that
the community's input is not only
being taken into consideration, it is
actively being sought after. The
framework has sparked so many
discussions and debates over best
practices that simply following along
introduces you to concepts you might
previously have been unaware of. I
would actually recommend learning the
ASP.NET MVC framework for this reason
alone. The threads on TDD, BDD, ORM,
AJAX, etc. you stumble across during
the learning process are worth it.
So there you have it. Aside from
those three, I can't think of any
other reasons why a developer would
learn ASP.NET MVC. Maybe this is why
the adoption rate isn't nearly as high
as we think it should be. The
incentive for using the framework
essentially boils down to unit
testing, control/extensibility, and
boredom/curiosity. Good reasons, to
be sure, but hardly game breakers for
the vast majority of developers out
there.
Control over the HTML output - is one thing. All those fancy controls SERIOUSLY SUCK from a SEO point of view.
Plus for COMPLEX forms, the ASP.NET state model is hell, too ;)
Anyhow, an example is your search box... it sucks ;)
I would use MVC like this:
Search is a URL:
/search/keyword
or
/search/keyword/pagenr (like /search/programming/5
Good thing is: I can easily have search results spidered by google - some sites I Know get most hits from something like that.
Is it harder to program than asp.net - depends whether you want efficient HTML or not. THe control model from ASP.NET does not lead to lean defined HTML somehow.
Besides that - MVC is a lot more testable. Unit testing a classical HTML site is pretty impossible, the decoupled model of MVC makes that easier.
I don't come from a Microsoft background, so I might be missing something strictly related to ASP.NET but MVC isn't something different than ASP.NET. MVC, or model-view-controller, is an architectural principal in software design that isn't strictly for the web. Graphical user interface applications commonly use this model.
Anyway, your question is dealing with the "why". The search listing page is a good example to start with. With MVC, you can use templates to only modify the visual aspects of the search (the view). You can add buttons and format what the controller gives you without having to make changes to the controller itself. Similarly, with a view you can change the logic of what is "given" to the view without actually changing the view. Finally, you can go from a relational database to an XML database and without having to worry about changing any of the other aspects of your program. The logic is separated cleanly and this pattern fits many use-cases.
I would highly recommend seeing the Wikipedia article on MVC. It may be easier to understand using a graphical user interface (GUI) example instead of a simple web based example.
Ryan
MVC is considered as an alternative to good old asp.net, not the next step. IMHO MVC has a clear advantage if you want to write unit tests for your pages.
But I don't agree that MVC adds anything to classic asp.net in the name of performance, code quality or productivity. You can achieve same performance with asp.net by shutting down viewstate when not necessary or you can be more in control of HTML output by using lightweight server controls. (Repeater instead of DataGrid for example.)
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
For months, I've been considering downloading Microsoft's express web platform and learning ASP.NET, which I might actually enjoy, seeing as I already do web work with PHP, but am much more comfortable with C#.
However, the primary reason I don't want to do this is that I've always associated ASP.NET with useless spaghetti HTML. The link I posted is an excellent example. Would it be possible to use ASP.NET in a context more similar to PHP, using it to power my site but not leaving the HTML, CSS, and JavaScript to be done by hand for validation and semanticity reasons?
EDIT
I've decided I'm not going to learn ASP.NET and stick with PHP.
While MVC sounds nice, for me it will likely end up being a development/debugging headache.
Things get much better if you use ASP.NET MVC. I recommend you skip ASP.NET WebForms and jump to MVC directly.
If you are going to use Classic ASP.NET Web Forms, you really need to learn how it works to avoid truely ugly html. If you know what you are doing, you can get close to what you want (you can't completely get rid of ViewState & it will do some ugly thing with element IDs)
A lot of the ugliness of Classic ASP.NET occures when people write web forms like they wrote VB 6 Windows applications.
ASP.NET MVC is a good option. It may be the way to go as a starting point; I would like to switch to it myself. I guess my point is that you can get less ugly HTML using Classic ASP.NET.
you're really going to want to check out the asp.net mvc. it allows you to develop in a manner a lot more suited for the web than vanilla webforms.
First of all, ASP.Net, even using webforms, does allow you to have complete control over the markup output. Of course it's easier for some cases than others, but anywhere you find you're not getting the html you want out of a control you can always replace the render behavior with a ControlAdapter.
That said, as others have mentioned you'll probably find it's much easier to get the exact html markup you want using ASP.Net MVC.
MVC.net and WebForms are built upon ASP.net
You can get a decent amount of control with webforms by disabling viewstate and not using any controllers (or very few). Its all in how much you let it do for you
If you are looking to acquire skills in the latest and greatest, then MVC is where you should start but I would also consider whether you will ever be asked to support ASP.Net Webforms. Having an understanding of ViewState is crucial to that end.
For fine grained HTML output, you can produce this in many different ways with classic ASP.Net. There is a growing group of developers who are using a mixture of ASP.Net and microtemplating with Javascript to produce RIA's. This inevitably leads to keeping your html output cleaner so that it can be manipulated with jQuery and CSS.
Learn ASP.NET MVC as it will give you more control over the html generated. Also learning ASP.NET will increase your job opportunities significantly.
My first real development in ASP.NET was with MVC, and I must say I truly miss it now that I'm onto the next project using webforms. Each has it's place and webforms is working pretty well for what I'm doing (also using it as an opportunity to learn about TableAdapters and what not) but I really do miss being able to insert the data I need right into the HTML. That way I know the layout I've built won't get screwed up.
As a framework I enjoy ASP.NET quite a bit, but the controls on the page seems so far removed from anything resembling HTML that there is often a mental disconnect with what I'm typing with what I'm expecting to see. I was that way when I first started HTML though, so I imagine I'll get used to it. When I started with MVC it was overall a much more enjoyable experience coming from a front-end background.
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...