I am new to the asp.net world (but not new to .net) and I have been playing around with various things to see how I want to architect a web application I am developing. In my playing around I have decided I did not want to use asp.net's controls, as I have done enough php and ruby on rails to be decently familiar with regular HTML, and a decent amount of javascript.
I see a lot of comparisons between asp.net webforms and asp.net MVC, however when ti comes down to it I am not seeing that much of a difference (and I'll admit that it's probably me missing the differences rather than them not being there). I already have coded my asp.net application using a MVC type of architecture (aspx has the view, aspx.cs has the controller code, and models are separate classes in the app_code directory).
If I do not intend to use asp.net controls and just intend to use pure html and javascript, what are the advantages of using the MVC framework? As of right now, the only one that I am seeing is routing, and I'm sure if I look more I can find easy ways to do custom routing without using the whole MVC framework.
Anyways, if anyone could go into details of asp.net webforms minus the asp controls versus mvc framework, I would be greatly appreciated.
You're going to find a number of differences and reasons to use MVC over WebForms but it's going to depend on whether those differences are important to you or your project. Routing is definitely a big advantage for MVC. Although you can implement custom routing configurations in WebForms it's significantly less intuitive.
Another big advantage is unit testing. Along with an IoC container and a mocking framework, MVC makes unit testing a cinch. It's much easier to isolate actions and behaviors with MVC and test those specifically.
A third advantage is that MVC will help reduce the spaghetti code you're going to write. If you're not planning on using any User Controls then it won't be long before you're missing the HTML helpers in MVC. The Html, Url, ViewModel, TempData, etc make working with raw HTML much easier.
The inherent validation in MVC is also impressive. It's getting better in MVC2 and now with the integration with client side validation libraries it will save you a ton of time and add a lot of functionality.
No more VIEWSTATE.
There are many others but again it depends on whether those features are important to you. Good luck with your decision!
ASP.NET MVC is built on interfaces, which makes it extensible, easy to write unit tests for, and encourages clean, loosely-coupled architecture.
If you're using 'classic' ASP.Net without using any of the server-side controls, there's not much of ASP.Net that you're using -- it's basically classic ASP with .Net instead of VBScript behind it at that point.
Giving up webcontrols is the biggest reason not to use ASP.Net MVC. If you're fine giving that up, I'd just use ASP.Net MVC and be done with it. It's got all the parts you'd need to write yourself anyway, and the parts you don't like, you don't have to use.
In my playing around I have decided I
did not want to use asp.net's
controls, as I have done enough php
and ruby on rails to be decently
familiar with regular HTML
Thats not a good reason to decide against ASP.NET controlls. The importand thing about ASP.NET is Viewstate. It allows you to use event driven programming in Webapplications. This makes a lot of things very easy and productive.
Anyway - as you know ruby on rails I guess you will pick up ASP.NET MVC pretty fast.
First up, if you use ASP.NET MVC you'll be using a supported framework that has books, online resources and hundreds of blog posts surrounding it.
Second, I suspect you need to play with ASP.NET MVC to see it's power. There is way more than WebForms in ASP.NET MVC. For many, the fact that WebForms is optional (you can use different view engines) is a major plus.
For me, the extension points, the cleaner code, and the unit-testability of everything I do are major reasons to never go back to ASP.NET "classic".
My recommendation to you is to get a decent tutorial (look for the Nerd Dinner tutorial), play with ASP.NET MVC, and find out for yourself.
Note: ASP.NET MVC is not for everyone, and if you're heavily into the post-back mechanisms in ASP.NET, or have a heavy investment in server and user controls, then you might not want to take ASP.NET MVC right now. But for your next project you should at least know what your options are.
Related
My company is trying to make an informed decision about how to pursue future development.
We seem to have narrowed down our future internal and external Applications to being web applications. But we are still a bit confused from that point.
There is a large amount of support for Sharepoint here. As I understand it, Sharepoint is basically ASP.NET using MVP.
Others want to use normal ASP.NET using the newer MVC style.
I am also told that these don't easily play well together.
It is looking like Sharepoint (and ASP.NET MVP) is going to be the winner. Before we go that direction, I wanted to ask:
If we choose to base the next 5-10 years of our development efforts off of Sharepoint (ie ASP.NET and MVP) what are we giving up? And is it a big deal or just some "nice to haves" that we are loosing.
(It would have to be a fairly big deal to get management to change direction now.)
Whatever happens, WebForms will turn into a big ugly mess at some point. If you have to use webforms, don't use the postback and page lifycycle model - have aspx pages with presenters for get requests, and have a handler or empty aspx per post. It'll feel a lot more like MVC that way
I would say that what you choose depends heavily upon who your developers are, and what kind of apps you intend to build.
If you build largely crud-like apps that make a lot of use of third party (or your own) custom controls, then staying with Webforms is probably a good idea.
If you build largely "web" style apps with lots of client-side functionality, then MVC is a much better choice.
If you have largely newbie developers, Webforms may be better. If you have more experienced developers, even if they're new to asp.net then MVC may be a better choice.
If you are building very data-centric applications with complex interconnections, then MVC may be a better choice.
There are lots of reasons why you might choose one or the other, and it's always "it depends on...".
Also, MVC and Webforms are not completely incompatible. You can't use them in the same page, but you can use both in the same site. Also, like the comment above says, Sharepoint is not Webforms or MVP per se.. it's kind of it's own thing that is based on webforms. It's very "Webpart" oriented, which is just a way of saying you build lots of custom controls.
I have been a strong proponent of Separation of Concern (SOC) being built into software whether you use MVVM, MVC or MVP all three patterns are quite nice. With this being completely specific to ASP.NET, I would state you should use MVC3.
I have been a .NET developer for years now and have written my MVP pattern that is built on top of StructureMap (lots on my blog about it) and for a while I never saw the benefit of dealing with the changes associated from leaving webforms to goto MVC. However after dealing with ASP.NET for so long I've just had it with ASP.NET webforms errors that are completely out of my control.
The main errors from webforms occur with the ViewState timing out resulting in the generic cryptographic exception and the 2nd is where the ViewState is just truncated by the client or post somehow resulting in legitimate cryptographic errors. With MVC these errors just aren't applicable anymore. With .NET4 I attempted to create a webforms application without ViewState with the new features they added in .NET4 and that completely didn't work which cemented by decision that webforms time is past.
Out of MVC, MVC2 and MVC3 the feature set that comes with the MVC3 and the Razor view-engine is the most robust. You get all of the enhancements that came with MVC2 along with the much cleaner Views that the Razor view engine lets you create, on top of that you get global action filters and the baked jQuery client side templating (I'm 90% sure).
I would also approach MVC very similarly to MVVM where I would have 3 distinct sets of entities, my view models, my domain entities and my physical database models. (The last set may, or may not be the domain entities, I've started to realize trying to make your pure domain entities work with your database layer can be suboptimal at advanced stages)
If you are performing page post-backs to handle events, I would suggest MVP as the Presenter would contain the event handlers for all versions of the view (Different user interfaces such as web pages, iPhone, Android, Windows forms), with a uniform behavior. In other words, you would not need to write control events in a code-behind for every view. At least, they'd do nothing more than call the Presenter's event handler method or raise an event the Presenter handles.
If you are creating web applications and heavily using Ajax for page updates, with one or more web views and a cross-browser JavaScript library, such as jQuery, I would recommend MVC.
So it comes down to how you want to handle page events. MVP & MVC both have separation of concerns. MVP is more server based and easier to add multiple UI's and MVC is more client based, for event handling and more web centric.
From my experience, a strongly enforced MVP pattern has been much better for data centric complex LOB applications.
MVP offers greater seperation as your presenters have no knowledge of web centric concepts.
Code coverage is also increased as you have no conditional code in the views.
We have several apps that where the presenter is used between both web and windows apps.
You presenter referes to a complete abstraction of the view, asp.net MVC relies on abstractions of view dependants (HttpContextBase etc.)
That all said you need to design this into web forms, its not out of the box, but if you do it right first time and have developers that understand it and stick to it you end up with a very clean solution.
there are some solid frameworks out there to support MVP in webforms:
http://www.codeguru.com/csharp/.net/net_general/patterns/article.php/c15173
webformsmvp dot com as well.
I´d like to know what is the best option to develop an auction site like Ebay with ASP .NET 4.0:
MVC 2.0
WebForms
I only worked with WebForms, but I have time to learn MVC if is the best option...
What you think?
MVC, but if you choose to use MVC do take the opportunity to write unit tests for your components. May I suggest a Test Drive Design approach?
While you are at it, you might also want to look in to Behavior Driven Design (it is like TDD, but few levels more abstracted)
This article http://www.lostechies.com/blogs/chad_myers/archive/2009/04/27/to-mvc-or-to-webforms.aspx has good arguments why you would want to use MVC over WebForms. You can read through the 4 bullet points and if they don't bother you then WebForms will be fine.
In a nutshell.
WebForms are fast to develop.
WebControls add ViewState and have
PostBacks.
If you come from another language
WebForms might not be OO enough for
you.
WebForms are difficult to Unit Test
If you anticipate a high volume site then not having ViewState and being able to unit test should be important to you.
I would recommend MVC, because I would recommend MVC for anything! It is easy to pick up, and you will probably never go back to webforms.
Besides the simplicity and the clean mark up. If you are working with any sort of generated code, the model binding makes developing pages really fast and easy. I have used a custom generated BLL and DLL, when the DataAnnotations attributes are generated all client side and server side validation is automatic.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm doing some maintenance on a classic ASP application for my client, and as I'm looking through the ASP, the following question comes to mind - would it be easier to convert a classic ASP app to ASP.NET MVC or ASP.NET WebForms?
In many ways, it appears that at least the HTML of ASP might be easier to convert to MVC than it would be to rip out the HTML chunks and turn them into ASP.NET controls, repeaters, datagrids, etc. Plus having to add in handling and logic for ViewState, etc. might be added work.
I don't think my client will be requesting any upgrade like this, so this is just theoretical.
Let's assume that this ASP code is written very well (which isn't always true of course) so really the question is, will a best-case-well-designed ASP site migrate better to MVC than WebForms?
(Note that I'm very new to ASP.NET MVC, so I might be missing something crucial here).
It depends a lot on how the classic asp app is structured.
The server tag mixed in with HTML is similar to asp.net mvc but MVC is not as messy (or not supposed to be). You might be able to move the classic asp presentation code to a MVC view easier than to a web form. Also classic asp apps were usually developed with the statelessness of the web in mind. There probably is not anything in your classic asp that matches postabacks or viewstate. Classic ASP also uses normal html elements as opposed to asp.net webform controls. In these respects it matches MVC a lot closer than webforms.
If you do not know asp.net webforms or asp.net mvc I would say MVC is the way to go.
If you know webforms very well and don't know much about MVC I would say webforms is the way to go.
But, if your client for some reason does want a redevelopment of the site I would say go with MVC. It's always nice to have a client pay for part of your experience development as long as you can deliver.
On another note I'm always taken aback when I come across a client who wants me to do work on their classic asp site. In every single case the site is a mess. The worse part is that they are usually filled with huge security holes.
I think in a lot of cases it could be easier to convert to MVC than Webforms. Most classic ASP apps demonstrate very little separation of concerns so the biggest task is probably exactly that, seperating out the logic into data access, business logic, business entities and UI components. In doing that it could well be easier to convert the inline ASP code to a view, the business logic into controllers and the business entities into the model.
I don't think one would be easier to convert then the other.
You can code ASP.NET almost the same as you code ASP if you wanted putting a few crucial elements in the codebehind that you could access in the aspx. No databinding, no gridview and no repeater. The view state is there to help you can is easy to figure out, it is not necessary to use it if you don't want and can be turned off in the web.config and turned on with a page attribute. Web forms also have an AspCompat mode which allows access to Request and Response objects or asp, which will allow for page by page conversion if desired.
As for MVC.net, the method for displaying the HTML is quite similar. That in my opinion is where the similarities end. You would still need to separate out all you logic into the MVC model.
Coming from ASP and going to Web.Form and now MVC.Net I can tell you that WebForms were a little annoying/frustrating to learn, with 90% of the MS tutorials teaching you the worst possible habits IE (SQL connections on the page, dragging datasets around in designers). However, once you get past that one is able to do a lot of thing much more quickly then in asp(pagination or build a simple datatable with editing for example), I have however STILL never seen a large webforms project with an n-tier design that I thought was easy to follow, implement and use.
MVC.NET is like a godsend. It forces patterns and practices down your throat, it has strict rules that are adhered to by most. It allows for easy code coverage and separation of concerns. After being frustrated with webforms for years it finally feels like I am not hacking things together when attempting to do something that I cant drag off the tool bar.
I personally would try webforms so you will know how much better MVC is when you start using it.
There is more to ASP.NET-MVC than the apparent similarities between view code and ASP inline code. There is all the Model and Controller parts to consider which is very different from the way most ASP is written.
That said I would say that MVC would be the best place to start.
IMO WebForms attempt to hide html too much for my liking and may cause your project to take longer than you would like due to converting a lot of html into the webforms controls.
On the other hand MVC allows you to reuse some of this logic while making your application much more maintainable and with the appropriate Architectural Pattern your application can be developed and refactored much quicker than any WebForms project.
I say MVC all the way!
Either way, it's always best to start from scratch and implemented only the logic.
I started ASP a long time ago (more than 12 years ago) and only in 2006 I moved to ASP.NET 2.0, not even today I know all, but I do know pretty much what I do everyday at work.
In my opinion now, and looking back to my knowledge of ASP I would go to Web Forms instead of MVC, first, it's a language that it's in the "market" some some yeras now and very used across the world, while MVC is still in Beta, so, not suitable for production environment (says Microsoft - even if this site is written in MVC).
I do tend to make confusion with MVC diagram still, and there are more tricks than I want to learn if I need to do a fast change of one ASP project.
It depends. The ASP.NET MVC is no silver bullet and in many ways takes a few steps backwards in terms of developer productivity.
If you have a tight budget and need to get this done fast I believe ASP.Net is the way to go since it has the wealth of controls like grids, paging, validation etc that you can use right out of the box. Using these controls will no doubt save a lot of dev time. All of these controls that most consider pedestrian by now in ASP.NET all have to be created from scratch or taken from the Internet when you use the ASP.NET MVC project.
On the other hand if you have the time and budget now and going forward, and you want to have a solution that is rock solid, and more easily lends itself to test driven development, the ASP.NET MVC is probably the best choice.
Definately ASP.NET MVC is better in terms of style. (That said, you don't have to use Repeaters and other silly controls in a WebForms app, you can simply use inline code just like you would in MVC.)
MVC in general though would be an easier port, give you a better structure and be a more pleasant experience.
Web Forms is more object-oriented, while MVC is like classic ASP on top of .NET code. Model design should be the same using Web Forms or MVC. The only difference is that Web Forms has an object-oriented abstraction to the UI and MVC uses functions and code snippets instead of classes to organize UI code.
ASP.NET MVC is better than Web Forms for automated unit testing of the UI. However, automated unit testing in general is bad practice and even worse for the UI. Manual testing is the best way to build a quality application and to make the best use of development time. Creating automated unit tests is a waste of time and you end up with junk code to maintain with the core code. Lots of developers like automated unit tests because they think they are proof their application works, which is false. They also are trying to avoid designing applications using UML so they are using test driven development to design using code which is responsible for poorly designed applications. With TDD, you are refactoring code you wrote poorly without thinking about the big picture using models in the first place.
So MVC is useless. Web Forms uses a better object oriented model whereas MVC is more like old style classic ASP and other older design patterns. This is 2010 and MVC is dead. Web Forms is like ORM for the UI.
If yes, when? and how much time do you think that the process will take to migrate your current projects (if it's the case)?
ASP.NET MVC is not meant to replace WebForms. They are different technologies and are designed for different purposes.
Making a blanket statement of saying that I'll only use one and not the other is a very narrow minded approach, as you're missing the pros and cons of each technology.
Microsoft is commited to both technologies going forward and there are quite a few sweet new features coming in WebForms 4.0.
I'll be using WebForms and ASP.NET MVC, but looking at the needs of the current project so that I make the right decision for the current implementation
I've been using it for a few months now. I absolutely love MVC. Converting existing projects may not be realistic, depending on available time. As I see it, Web Forms simulates windows forms development for the old VB crowd. While MVC doesn’t pretend it’s something it’s not and follows the Http process more closely.
A few plusses I see in MVC
1) It’s testable with unit tests
2) Direct control over Html. We make websites, how do we accept not being able to control all our html?
3) No viewstate baggage
4) No control tree to waste time rendering
5) Automatic binding of a modal from a form post
6) It can be rather sexy
And a few disadvantages
1) No more web controls (and many rich 3rd party controls are lost)
2) Slower to develop in
3) Large learning curve
4) Still in Beta (CTP soon though)
Yes for my new projects. But not for current production software.
Yes, in as orderly a fashion as possible.
MVC opens .NET up to the world of Best Practices for Agile development. It specifically addresses concerns about Separation of Concerns, and coupling/cohesion. It also lets us write more-portable software without creating a dependency on any vendor-specific references or components.
It unquestionably is a successor to WebForms, along with WPF, regardless of whatever PR you might read.
The Wikipedia entry is pretty clear, even before being updated for Microsoft's MVC.
Assuming you prefer ASP.NET MVC to Web Forms, it's worth it for a system that's in active development/maintenance.
They can coexist side-by-side, so it's possible to migrate parts of the application (new ones, or selected old ones) and see how it works out. If it's a success, keep going.
An "all or nothing" migration could be disastrous, though - investing a lot without quick feedback is a huge risk.
WebForms are for rich UIs
These can be done just the same with MVC or Webforms. A year from now rich MVC based toolkits will arrive (technically they're already here if you like YUI, ExtJS, etc.) and make this argument null and void.
migrate your current projects
Migrating an existing WebForms project to MVC doesn't make a lot of sense. What are you going to gain? Using MVC for a new project however can make a lot of sense depending on your requirements.
I was never really fond of WebForms to begin with so getting to work with MVC was like a breath of fresh air to me. I've always much preferred the separation of concerns as I could work on the chunks that I was really good at developing, the logic and the data access, and leave the presentation work to the members of the team who had that natural ability. I think the MVC library makes it easier for teams to work together on individual pages as one person can work on the controller and the other person can work on the view.
All that being said, when I'm working on projects where I don't need to focus as much on the coding and it is more display oriented, I still go back to the WebForms because they are so much easier to implement and get up and running. Both have their places and I don't think one will ever supersede the other.
I've been using ASP.NET MVC for several months now and I prefer it to Web Forms. However, I don't see myself migrating my existing projects to MVC. For me, it would be rather pointless. However, all of my new ASP.NET projects will (or should be) developed using MVC, as it is a much better (and more flexible) framework.
Personnaly I restricted ASP.NET MVC for lightweight Front Office Web Sites.
But still using ASP.NET WebForms for Righ BackOffice Applications to take advantage of rich custom controls and some of other nice features of Web Forms.
Another plus for mvc is that javascript like jquery is much easier to implement, so if you plan on using a lot of js, mvc might be the way to go.
No, there's no reason to. It's an alternative style, one I am not fond of. But that's just my opinion; a lot of people like it and I hope it works well for them.
As already said, they're not mutually exclusive, and I play to make good use of both.
IMO MVC is better for web sites, while WebForms are better for web applications.
For example, this site is a perfect showcase for where ASP.NET MVC is a good choice because of the nature of the site and what needs to be accomplished; other good examples would be a web store, or a project management site (like Basecamp), or a social network.
If you were developing a corporate CRM/ERP system, however, I'd stick with WebForms to get rich controls and a more "desktop-like" programming model, since a CRM application is traditionally the domain of a desktop application.
ASP.NET MVC fits my desired style of development better, but I'm wary of trusting myself to it whilst it's not been RTM. It also is different enough that our legacy code will not work with it. If we had been practising Domain-Driven Development things might have been easier, but ...
What are some helpful things that ASP.NET MVC developers could suggest that would help us ASP.NET WebForms developers to write better code/web apps?
I'm a WebForms guy but with all the new hype around MVC I'd value some comments on helpful tips, tricks and strategies that might be able to be used in a webforms app.
Something that occurred to me a while ago when learning about the new MVC framework, is that WebForms was, I think, an attempt at MVC in many ways. The markup and code-behind comprise View and Controller, and you're left to write your own Model.
This idea goes hand in hand with the important design considerations I gained from learning about MVC. The most important of which is solidifying the core domain of your system as a whole and making sure all common logic is defined at a level that is reusable within this domain. This is your Model, and I like to call the logic that lives at this level Domain Logic (I mix terms, I know). Your Model should be reusable across different applications (a main web/winforms app, winforms apps for utility and configuration, background processing services, web services, etc.). Your applications should stay very specific to their purpose: they consist of Presentation Logic (their views) and Application Logic (their controllers). Anything that crosses the line of needing to be used in other applications is easily classifiable as Domain Logic, and should not be part of the application code for any given application.
I hope that makes sense.
The gist of it is, even if you're not using a pure MVC framework or object model or whatever, this high level look at design can be applied with great effect. Isolate common logic in a domain layer that is reusable across applications and your applications are much easier to write and extend and maintain.
Forget about page life cycle
There is no ViewState (by default that is)
There are no postbacks
You need to know the HTTP protocol basics (GET/POST). The same goes with HTML (DropDownList is actualy a tag)
I would recommend geting started by watching the screencasts on Microsoft's Learn site:
ASP.NET MVC Videos
There you will learn the differences between the WebForms postback model, and the way that MVC directly routes your URLs to Actions & Methods.
The second major difference is to remember that in ASP.NET MVC you do not use controls that do postbacks. It might feel a bit more like Classic ASP where code is inline on the page within server side blocks, but it is worth it. You will have full control over the HTML that is generated, and this is very good for things like Search Engine Optimization.
Some advices
Don't use standard controls. Instead pay attention jQuery, MooTools.
Use strongly typed Models
It's good practice to use some IoC like Spring.NET
I'm also coming from webforms, but have been learning asp.net MVC since around preview 3.
I'm not exactly sure how to bring anything from MVC into webforms, they are two entirely different frameworks. I'm probably too new with it to understand how any of it could be applied to webforms, but right now it seems they have very little in common.
Some of the strengths of MVC are it's rigid structure on how you need to do things and where you put code. It also does away with the form runat=server and I believe does not promote the usage of any of the asp.net server controls (you need to write all the HTML yourself). That is pretty much the definition of webforms right there. MVC pretty much replaces webforms with it's own framework.
If you ever did Classic ASP or PHP, I would call ASP.net MVC a more structured framework for what people might do with those older scripting languages. It's kind of like the FuseBox framework, but even more structured and evolved.