As a .NET programmer for 15 years, I have been working on all .NET versions from 1.0 to 4.0. The important thing I learnt is "the simple solution is the best solution". Obviously, the MVC is not a simple solution (Its complexity is getting worse with Razor view engine in v4/v5):
1. Spaghetti coding style: that is as horrible as classic asp. When the page getting bigger, it will be too hard to read. If you never work on the classic ASP before, you will never know the pain.
2. Complexity of pattern: using such a complex pattern for a UI that can be done easily with web form ( html, ASP controls and JS) is not efficiency on time saving
3. Coupling issue: Any part breaking on M-V-C, it will affect others, because they are three in one.
4. Design can not be viewed in VS: Hate to comply it every time when I want to see the UI.
5. Performance issue: dynamic generating/routing the pages in runtime that gets penalty in performance. ( Taking off view state will not benefit the website performance because the data now are saving to the server side memory, it makes the server slow down. View state is very useful when we want to save some non secure info on client side)
6. Migration issue: Too many third party DLL(s),scripts and complex layers sitting on the project, when it is doing upgrading/migration, it comes out much more errors than web form. That is really pain in the *ss.
Anyway, it has its advantage: It is very good on Unit Testing. It could be better than Web Form in mobile development.
.NET Web Form has one big disadvantage, (well some people say it could be an advantage): It gives you freedom to code what you want to code. It has no limitation on technologies that can be implemented on the code. so, it becomes a problem when codes become too complicated. Anyway, a clean coding programming is really depending on a programmer's knowledge and talent - it is just like one's bedroom: if his/her bedroom is clean and tidy then he/she likely is a clean coder. Smile | Smile |
If you want a clean coding then try to adopt these rules: 1. Avoid coupling coding style 2. Use three - layer pattern to separate the codes 3. Always put performance in the first place 4. Avoid using third party DLL(s) 5. Simple solution is the best solution
Anyway, .NET Web Form is a powerful technology for all type of projects and it is very easy to be migrated to new latest .NET platform with less effort (if it contains few third party DLL(s)). On multiple users platform, you should really consider the .NET Web Form (.NET WF) rather than the MVC. The .NET WF will be able to save only security data in session id on server side and leaves all on-security data with encryption on client side so that saves a lot of memory resource for the server memory and let more users connecting to the web at same time - it could be thousands and millions. MVC will be never like that because it consumes a lot of memory on server side.
The most critical issue for WF is the weakness on testing.
MVC is built on top of .NET Web Form. The Web Form 5.0 is coming out soon. It has big improvement/changes on its UI technologies and will have impact on the MVC because of that reason. Keep it in mind: MVC is not a replacement of Web Form. MVC is an optional (and WF is fundamental core in .net). Before you get into MVC, think about your time, knowledge, resource and budget first. Once you get in, you can not get out unless you dump it.
(The best hot technologies now are HTML5.0, Web Form5.0, LINQ to SQL, ADO.net, WCF, .NET 4|5. Using these latest technologies, a programmer will be able to get everything done nicely.)
I was asking here and there since I m learning C# "what 's ASP.NET and MVC?" .I was getting confusing answers and didn't know what should I learn for ASP.NET .You made it clearer now and thank you for posting.
This is so one-sided, hardly objective when WebForms gets only one possible point. If you want to pretend that MVC is the only way to go, just say so.
With literally hundreds of "best ways" to accomplish a similar end result, I'd rather see a little standardization, so that a good programmer needn't be a 'jack of all languages' to be able to do a good job of analysing/improving code. We can each probably provide an example of a top 500 company's web offerings which just plain don't work -- unit tested or not.
We seem to forget that someone has to pay the bill for all of this technological spread we like to evangelize about. It is little wonder that we see such poorly written code, with oftentimes even worse business logic/design. We hop on/off bandwagons like kids on a merry-go-round.
Yes, I'm all for progress and improvement, but lets just admit there are many ways to skin a cat. Newest is not necessarily best.
Nor do we need to invent 10 more ways to do so each week. Web programming need not become rocket science, though it seems to be headed that direction.
"The best article about MVC I've ever seen" ?? Kinda makes my point.
I am familiar with web forms but have no experience in MVC whatsoever. I read quite a few articles about why MVC and what advantage does it offer, including Microsoft's own introduction. This article is by far the simplest but spot-on. It cut through the mist of the technical details, and lets you know immediately all the whys and reasons. Author must have a very strong capability to see through millions of details and see the most important issues.
My opinion after spending a year writing MVC apps and as a project manager:
- Tag soup galore in the mvc views , extremely difficult to manage or even debug and reminds me of the classic ASP , php even cgi primitive development
- As a project manager with a lot of existing Webform apps to maintain I find it hard to find new employees that are willing to jump into both worlds (mvc and webforms) so when we post for jobs first requirement is WebForms, if you don't have experience with that you don't make it in the interview room
- even if you create Html helper extensions to encapsulate a lot of html, is not as readable as code behind.
- Webforms markup and code behind if written correctly can be as fast as MVC and we can buy server controls like Telerik that are tested and work both on a tablet or a phone. Telerik now has mvc controls and we are evaluating.
The only advantage for MVC in our organization is testing
And testing should be enough of an advantage to sell it. Not to mention you can use IOC containers to instrument the application. Try do that with Web Form applications. I agree that you should understand Web Forms since there are many legacy systems, but if you are starting a new project, Web Forms really shouldn't even be a consideration. After all, MS is phasing it out and there are very few enhancements being made to Web Forms.
what the heck does that mean ?!
... Web Forms has Design/Split/Source view of the HTML page... I think that would means web forms has complete control over the HTML.
With MVC you have to guess what the page looks like and every time you make a change/addition to the UI, you have to browse to see what you have done....very inconvenient and not much control.
It seems that most people just follow along on the bandwagon no matter where it leads or how poor a choice it is. There's nothing wrong with web forms and MVC is for most web apps over-hyped and unnecessary.
I read this article to get a good introduction to a background of ASP.NET and WebForms. After reading a handful of similar articles, the background information could have been more detailed, but it was still a good breakdown. A nice bonus that made this one stand out from the rest - the article also provided a brief questionnaire for deciding to do a project in WebForms or MVC.
Many of the concerns you raised about webforms can be easily fixed. For example, if you simply cache viewstate so it is never rendered to the page you just eliminated the entire viewstate concern. The following is one means of doing that:
If you use web forms properly they can be extremely quick and powerful. I`ve tried getting into MVC but I seem to end up writing 4x the amount of code that I do in webforms. I`m not giving up on MVC yet though.
In your article you write "Model operates on database (or on some other data sources) and return data (in form of business objects) to controller."
When you look the image above it, the image shows that Model talks with Database. It seems from this image and description that Model is responsible of retrieving the data from the database. It may even do it when View is accessing Model. It would then mean that Model object (e.g. Product) depends on class which reads Product(s) from Database. Is this correct?
Earlier I actually thought the same, but then I changed my mind.
I think that Model is responsible of containing the data. Model is e.g. Product. Product does not depend on anything (except native .NET types). Controller is responsible of accessing the Database and fill the Model and pass Model to View.