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.
Related
I am not starting an argumentative discussion here and this post is not about career development, but from the commercial point of view:
If a company was using ASP.Net MVC as a main methodology to build their web sites and application.
However, ASP.Net MVC takes more time to show a functional application than ASP.Net Web Forms, for example, building domain models would take some time which obviously can't be represented on a UI at that current stage.
My question is, if a client wants to see a functional demo application (just a proof of concept) so he knows that the company he is dealing with is professional and capable of doing that. Would it be better to do that demo in ASP.Net Web Forms only to show the client, and then work on the real application using ASP.Net MVC? If not, what are the (quick) alternatives?, I mean, if we tell the client to wait till we have a working demo (by ASP.Net MVC) we may lose the client and the whole project opportunity.
WebForms being faster than MVC is a myth:
You are not required to have a domain model, just something that represents your database tables. This is the same in WebForms unless you are using SqlDataSource's.
The code in your !IsPostBack or btnSubmit_OnSubmit is almost identical to the HttpPost controller actions. Except with MVC you don't have to write left to write object.FirstName = txtFirstName.Text when you understand how UpdateModel works.
UI is UI. If you know HTML/CSS creating the UI is just as easy. Almost easier in MVC because you don't have to set control properties any longer and all UI can be done in one place.
Fast MVC comes from understanding how to get the most bang from your buck using EditorFor, DisplayFor templates. You'll need to know and understand how to customize your Object.ascx file. With this technique under your belt you won't have to create forms by hand anymore. 2 projects ago we had a site with 100% autogenerated forms. Change a class, change a form. Done!
Another helpful MVC tool is the DataAnnotations attributes. Validation made easy. Customizing these is really easy too. Just create your own ModelMetaDataProvider and starting expanding the validations your application can handle.
The only part of MVC that is slower is displaying a grid. MVC 3 already has a useful grid tool and MVCContrib has had a grid tool out for a year now. I ended up rolling my own, its very simple actually, loop through properties, write <td />'s. < 200 lines of code. This isn't really a benefit to WebForms either. To use WebForms grid components means giving up a lot of quality using ObjectDataSources and the like.
To summarize fast MVC comes from these different techniques:
Object.ascx
ModelMetadataProviders
UpdateModel
DataAnnotations
If you are more advanced and know ORMS like EntityFramework and how to use Automapper your probably going to be even faster.
You can get a demo up and running very quickly in MVC. I could put one together much quicker than with WebForms, and I am familiar with both.
The reliance on convention in MCV will help a lot, binding is based on the names of objects.
If i was creating a quick demo, i would just create a bunch of ViewModels with static data in them, different button clicks etc will just bind one of these ViewModels to the page.
Turbo Fast!
I build prototypes in excel. No logic, no code. just basically screenshots to show the user that we are communicating the same ideas. Create a worksheet for each "View" or screen you need to show. Client's usually only care how "pretty" an application looks vs does it work right.
This also is a benefit as you can include more non-technical users in the prototyping process, since most are used to excel. I can send you an example and the finished production web application, if seeing is believing. I personally learn best by example.
And to your post where you wrote...
I mean, if we tell the client to wait till we have a working demo (by ASP.Net MVC) we may lose the client and the whole project opportunity.
They need to have their expectations adjusted and managed. A lot of bad development has been done quickly over the years, which makes client's ask questions like "Bob did it in 1 hour'. To that I say, you can either have a lousy project fast, that you have to constantly duct tape or a well thought out and well written project that will only need to be enhanced as Bus Reqs change
I think the answer is obvious: use whichever you think makes you faster. There's no point in using MVC if you are faster in WebForms. Especially since this is for a throw-away demo.
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 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...