Related
I'm getting ready to be responsible for leading the development of a small ASP.net MVC application. This is my first time creating an MVC application, so I am excited!
I've carefully read over the documentation and I feel like I have the general idea of how MVC works. However, if I understand correctly, server controls (like GridView, for instance) are not part of MVC.
My question is: Why? At my development shop, I'm so used to using controls like GridView and the MS Chart Controls that I'm almost at a complete loss as to developing without them. It seems almost like starting over.
Why are the server controls unavailable? How does Microsoft expect me to work without them? What are the alternatives?
My question is: Why?
Because most of them depend on things like ViewState and the Postback models which are part of the classic WebForms model and no longer exist in ASP.NET MVC. Those server side controls rely on events that will perform postbacks to the server persisting their state in hidden fields (ViewState). In ASP.NET MVC you no longer work with events such as Button1_Click. In ASP.NET MVC you work with a Model, a Controller and View. The Controller is responsible for receiving user requests, querying the Model, translating the results into a view model and passing this view model to the View whose responsibility is to display it under some form.
In ASP.NET MVC there are HTML helpers that could be used to generate some reusable HTML fragments between views. You may take a look for example at the Telerik ASP.NET MVC suite of such helpers. They call them controls but they have nothing to do with classic WebForms server side controls. They are just HTML helpers.
Basically classic WebForms are a leaky abstraction of the web. What Microsoft did back in the time when they designed this framework was to bring existing Windows developer skills to the web which was getting more and more momentum. But since the web was still a new technology that most developers weren't yet familiar with, they created this abstraction to hide away the way that the www works. Those developers were accustomed to drag and dropping controls on their Windows Forms, double clicking on buttons that was generating some code for them in which they put their data access logic and so on. This model was transposed to web application development thanks to WebForms. The HTTP protocol was successfully hidden behind this abstraction called WebForms. For example you don't need to know HTML, nor Javascript, not even CSS in order to create a website using WebForms which is really great because the framework abstracts all those things for you. Unfortunately by doing so it prevents you from easily utilizing the full power of lower level web technologies which some people might need when developing web applications.
What ASP.NET MVC does is basically remove this leaky abstraction and bring the www to the developers the way it was intended to be by its creators. ASP.NET MVC is not mature enough compared to classic WebForms so you cannot expect to find the same range of available controls and widgets but things are slowly shifting.
I would recommend you start here with ASP.NET MVC: http://asp.net/mvc. Go ahead, watch the videos, play around with the samples and see if ASP.NET MVC is for you or not. And of course if you encounter some specific difficulty or question don't hesitate to come back here and ask it.
I'm so used to using controls like GridView and the MS Chart Controls that I'm almost at a complete loss as to developing without them. It seems almost like starting over.
In this case, starting over is good.
I've gone through a similar journey. If straight HTML scares you, try working with the System.Web.UI.HtmlControls namespace. This will allow you access to standard HTML controls, but you'll still have the comfort of turning them into server controls if you need to (either by specifying the runat="server" attribute, or by converting them into equivalent ASP.NET controls.
In addition to Darin's answer, there's another problem with ASP.NET: you're bound to Microsoft's view of the web. That GridView you love? It's generating bad HTML. The Paging controls it provides? Even worse. Even if you know very little about HTML compliance, nested tables should give you the chills. In a way, everyone who uses a GridView is lucky that legacy web supported by Microsoft (and to a lesser degree, Google and Mozilla) came from such a god awful starting point.
Finally, to summarize: my suggestion is that you try to rewrite your pages or develop new web applications (as best as you can) using HtmlControls only. You'll probably have to learn some JavaScript/jQuery, and might have to venture into the world of AJAX to make your controls operate the way you want them to.
Use this as a stepping stone into the world of MVC. You won't use the same technologies (and may drop a lot of JavaScript/jQuery), but it will help you change the way you think about web development in much smaller, and perhaps easier-to-absorb chunks.
Ultimately, however much you like your ASP.NET controls, you'll have a much greater degree of freedom, and you'll also be developing websites that make use of newer technologies, which will provide added value to your websites.
At the core of this is Model View Controller (MVC) which promotes decoupling. The idea is that you feed your View (web page) a Model with all the data that it needs to be rendered. Server controls are tightly coupled. There is no concept of state in MVC or 'should' be no concept anyways.
That's kind of the point of MVC. It takes away the high level of UI abstraction that server controls provided and leaves you with html and javascript. (It also adds some really cool model binding features)
I am new to MVC and have found using Partial Views to be similar in creating small, reusable UI elements that do not fit into the _Layout. For example, sliders, slideshows, navigation, featured sections although you can use #section for this I find partial views to be more beneficial. This concept enables me to create reusable libraries that I can switch out easily and use in other projects. To me this is similar to controls, although there is a debate both for and against this analogy.
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
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..!
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...