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.
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.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
What’s your choice for your next ASP.NET project: WebForms or MVC?
Can you list some reasons that would make you use ASP.NET webforms for a new project, instead of MVC? I've heard a lot about the opposite, but not things that are done easier or better with webforms. I'm not talking about developer preferences here, but rather technology features and how they map to project features.
The only argument for WebForms is the need to design highly complex (read cluttered) interfaces with a whole lot of interconnected elements which in all or in part should react to changes in other elements.
A typical example would be some enterprise application (from SAP or smaller vendors). They usually have interfaces bordering madness. You'd have a hard time trying to synchronize the controls manually with JavaScript if you were on MVC. With WebForms it's by far easier.
Whether it is a good idea to build such interfaces is another matter entirely.
In WebForms element events trigger a page postback. They go to the same url and are processed in a unified manner. This is what makes the architecture very scalable.
With MVC to accomplish this you would have to set up a bunch of service urls to handle posts from different controls, then process those posts and update view models accordingly. This all involves a lot of trickery and juggling. Not that it is not doable - it is, but not on a big scale. This approach would not be scalable. Sooner or later you will arrive at the understanding you'd need to build your own framework in the direction of stateful object-oriented HTML/HTTP abstraction like WebForms.
A few things that could push me (back) towards WebForms:
I need to produce something that can be taken over by someone who isn't primarily a web application developer (say a WinForms programmer), and the app could substantially be maintained through Visual Studio's Forms Designer. The IDE support makes the development model closer to that of WinForms.
An app that needs to look Ajax-y but will be maintained by someone who won't learn JavaScript. I think things like the UpdatePanel (while horrible in so many ways) are actually pretty good for that scenario.
Possibly for some kind of demoware, again because of the IDE and ASP.NET AJAX. Fairly quick to knock up some reasonably smart screens without too much thinking.
I need a powerful CMS and need to stay within .NET. At this point it looks like there's better choice in WebForms than in MVC (though hopefully that's changing).
I'm working with a team who are already familiar with it and aren't going to learn MVC.
Of those, probably the CMS is the requirement I could think of right now that would actually make me use WebForms.
If you only know webforms MVC comes with a learning curve so you will need to spend quite some time training (or risk making serious security or performance errors)
You need a tiny little app NOW It probably is quicker to build a throw away mock application in webforms if you go for the anti-pattern. E.g. SqlDataSource, Logic in your code behinds etc.
Rich controls GridView is an excellent control, having sorting etc all built in for you with little code needed as long as your custom requirements are small.
Lack of web development experience Web forms is just easier. It takes more concerns off your plate. Much better for a newbie as its tough to go wrong.
Having said that, if you know what you are doing or have the time to learn and you want to build a long lasting site, MVC is soooo good. And more fun too.
I'll add that there is nothing really wrong with web forms. It's perfectly possible to build high performance app with it. It's just times have changed since it first came out and MVC has addressed those changes well.
Personally, i find MVC very good for admin-pages. because they usually have a load of tables, and are made for data input and editing. MVC is 'made' for those things, so it's going very fast making those pages.
webforms I use for more complex things, like the User-end of the site. the site i make shows courses people can take. the registering for a course is a 5 step procedure, which in MVC, I have no real idea how to do it. I'm sure it can be done in MVC but I think it's better/faster in webforms.
however in the end I do like MVC more. It feels so much cleaner to work with.
The only time i would consider going with Web Forms in a new project is if there was a component created for Web Forms that solved a specific problem that would be much harder to solve using MVC.
I can no longer see any advantage of Webforms over MVC, apart from some upskilling effort which should not be prohibitive.
[Originally I believe MVC wasn't compatible with webcontrols, so wishing to use Dundas chart control for example wasn't possible. That would have been a good argument for using webforms depending upon your requirements. But I believe this is no longer the case, and anyhow, you can include webforms in your MVC project as a worst case.]
It depends!
The difference between WebForms and MVC is if you can TDD and control the complete markup.
I 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 my existing web site developed using ASP.NET.
It's college management system. Now I need to redevelop it on MVC2.
What all changes do I need to do?
I am little bit aware of MVC and have done some exercises also.
Thing I know is I can keep my database intact but there will be massive changes at other places.
WHat will be the better way to minimize the changes?
MVC is a very different concept from event-oriented WebForms. There's good chance you will have to redo the frontend completely.
Try to find out if there is anything resembling data access layer and the business logic layer. If so, you can keep them (at least partially) and reuse their methods.
However, if the current application is not well structured and looks like a giant code blurb (with no layers, parts of the code talking to any other part at will, page methods going directly to the database etc.) it may have to be redone entirely.
If the application is now heavily relies on data-bound controls, you're screwed. You will have to recreate a lot of functionality by hand.
You should be able to refactor the middle tier (if you're using a multi-tier approach) into controller/model while keeping the UI intact. Once you've done that, throw away your UI and write a proper View. Try using LINQ-To-Sql for the backend.
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