Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Aug 27, 2010 04:30 PM by mad-halfling
Jul 04, 2008 12:07 AM|LINK
valid points made ... but don't forget ... when newbie developers (and that was every single one of us, when we started ASP.NET development) learnt the basics of ASP.NET .. we used most of the OutOfBox default stuff ... which is where we all learnt to accept
bad control crap. But we can sit here for ages highlighting the pro's and cons of the webforms model .. but that's not the point of this thread. This thread is about the pro's and con's of ASP.NET MVC and, IMO, rebuking the false accusations asserted in the
MVC should generate a new league of web developers that can be proud of their lean, mean and sexy-hawt code. Time to catch up on lost ground.
Jul 04, 2008 02:18 AM|LINK
I understand the rationales behind the MVC framework besides the fact that Microsoft has always loved the MVC pattern, which is to create a unified architecture for web applications.
But, there is no unified architecture and there won’t be one. And developers have to come out their architectures themselves. The only benefit I can think of MVC is performance as you have to do everything yourself, of cause you can achieve better performance.
But if I worried so much about the performance, why do I choose ASP.net in the first place? I can always write ISAPI or CGI. Or, I can use PHP with apache which always fly
J. The reason I choose ASP.net is the low cost of development. And MVC
is everything against it.
Jul 04, 2008 04:24 AM|LINK
Wall.Of.Text part ][
Please dude .. paragraph your stuff so we can read it more efficiently. Anyways, back to the discussion (gawd i hope Phil Haack, Scott Gu, Scott Hanselman,
Brad Adams, Tgmdbm or some other MVC pro can help me out here...) .... Where to start ???
The answer is it follows the OO principles ant that is you put method and data related into one class
You put your UI logic (not business logic) in the event handler and you put your business login in separated assemblies for reuse by other front end. It is straitfoward and works well
Why do you need put your UI logic in 3 separted class, the view, the model, the controller
Back to your assertion about UI logic in 3 seperate classes. Incorrect. It's in ONE class -> the controller. ZOMG. This is still OO principles (zing!). I've discussed what the view is and that does not have any logic in there. What about models? I like to
see models as UI -independent- logic. For example. A method that determines the price of a car, based upon some properties (eg. colour == red means $100. colour == blue means $150, etc). This has nothing to do with UI. This logic could be used in a webservice
or .. i donno ... mobile web site or some windows desktop app. This is the true use of a Model IMO. It's logic that knows nothing about the UI. The controller is the only thing that knows about the UI .. because that's it's job.
The controller is a bunch of methods that represent the actions of the user. It's the brain in the middle. And yes .. this is still OO principles if you're so keen to throw that one on the table. Classes and reuse of logic.
You ended up with high coupling among these three classes and you ended up with increased difficulty in maintenance.
I totally agree that ViewState need improvement, because it is unnecessarily
huge. Thankfully I can put the ViewState in memory on the server side
Ok .. the MVC fanboi's are of the belief that (with regards to viewstate) that this is AVeryBadThing(tm). The viewstate is an attempt to try and make the stateless environment which is the web (and IMO this is a good thing .. stateless environment that is)
to a statefull environment. Totally understandable .. especially since i take it you've come from a stateful background with your MFC stuff. I'm drawing a big bow (as in bows and arrows) here and your understanding the pro's and con's of statefull vs stateless.
Now even though we have viewstate (which is trying to make it look like we're in a statefull enviro) it's really not. sowwy. To do that, all the data is getting saved (persisted) at the cost of the devloper having to declare what is required to be remembered.
Now webform fanboi's could say 'enabledviewstate = false', if u're that pedantic. Firstly, everyone should be that pedantic. Secondly, it's the POINT! The application should be lean enough Out Of The Box that there is no requirement to 'remember things'. When
a user requests an action fro the server (eg. show me all the products / display all the info about that Jaguar car) .. all the bare minimum client information should come across the wire with that action-request. The developer (IMO) needs to think strongly
about what each action a user can do and code to that. Right now, the developer only thinks of pages, not actions. Then they don't think about what is really required for that action. it's 'always just there'. woopie. This is dumbing down the developer to
no-end, IMO. This creates more problems in the long term, IMO. It's Idiocracy for developers.
So many say 'Sif i care? It's works. It's fine ... and I can do the job SOO much faster because the viewstate and all this pretty little controls remember their state, I don't have to waste
my time having to remember it all'. Well .... stick with web forms then. If you think it's good - more power to ya. Some people (us MVC fanboi's) like to keep things lean and tight. Does it take us longer to do? nope. Is there more code? nope. In fact, it's
taken me less time to do certain stuff with MVC that with web forms and i've been doing webforms for a decade now.
I digress :(
I don't know since when MVC become the "Standard".
Web form controls, they are just great, only if you know how to use it properly. I have been doing HTML since 90’s and I think the HTML spec sucks
No matter what, though .. when you're doing web development .. the result will always have to be HTML sent back to the user/browser
(ok .. json/html/xml/text/binary are a pretty good list of response types .. but you get the idea what i'm trying to say). How yo ucode that ... well MVC caters for all. Can't do that with webforms eh? But really, that's a moot point .. cause the designer
r0cks and drop and drag controls ftw!
What is the logic you have an <input type=text…>, but you don’t have <input type=list...>.
Talking about CSS, please let me know who hasn’t been frustrated when CSS goes wrong? Why, because HTML and CSS is unti-OO. What is wrong to have a <textbox> or <radio> or <checkbox> element?
Why can’t you have element specific CSS? See, this CSS applies to textbox and this applies to checkbox and this applies to layout of the form.
And this is what programmer always thinking, class, object, interface and patterns
OK so what is MVC is about, it doesn’t work with web controls and it doesn’t work with Ajax control kits and it doesn’t work with millions of controls
that you can download from internet. So, what is the benefit? What benefit it brings in, does it speed up development, does it improve performance, does it improve maintainability?
At the end of the day, if you find that a gridview saves you
weeks of work because .. it is really really easy to use a gridview, set some styles and viola! it's all working .. then more power to you. I've not been a fan of it because of the viewstate footprint it provides AND because i don't believe in the concept
having all that state remembered when IMO I like to handle user actions differently to the web form model.
Neither are right or wrong - it's just a different way to do
Hmm.. why am i still replying? Too late now .. must... continue.
Suppose I have a Page with 5 tabs and on each tab I have 30 fields and 2 of the tabs I will reuse in another page. And I want use some nice date time picker from the ajax control kits. And I need lots of client
side validation on the controls. Please tell me how you could do it with MVC in a timely manner???
(loose quote). blah blah blah. Use Ajax to speed up page loads cause viewstate sucks. blah blah more postback blah blah
When I look at the MVC northwind examples from Microsoft, I am sorry it makes me laugh. All the classes are stateless!!! The only exception is
the NorthwindContext class, which put logic on different data tables into one big fat class!!! This is not object-oriented programming. One challenge of web development is to make the stateless HTTP state aware. MVC is going backwards! OK, you have to manage
the state yourself. Of cause, I can. But why??? I want a framework CAN help!
I understand the rationales behind the MVC framework besides the fact that Microsoft has always loved the MVC pattern, which
is to create a unified architecture for web applications.
nearly there ... well done for reading this far, reader!
The reason I choose ASP.net is the low cost of development. And MVC is everything against it.
Stick with web forms dude because you don't understand some of the reasons why people are finding the webforms model difficult to work with. Also, read this very simplistic overview
of MVC from Guru Gu:
http://weblogs.asp.net/scottgu/archive/2007/10/14/asp-net-mvc-framework.aspx It helps highlight some of the nice things we like about it. Now, if you're ready to ask some questions instead of making uninformed accusations and assertions, we'll play nice
and drive around together, holding hands with our hippie VW's.
Jul 04, 2008 04:37 AM|LINK
I'll probably regret commenting on this brave troll, but the clock just passed midnight and I just can't help but tossing a few cents into the kitty. First, let me just say you should feel free to use webforms if you prefer webforms. The MVC community
at Microsoft is going to always be dwarfed by the webforms community. If it works for you, don't fix it. Wait, what's that sound? Oh, it's just Sgro having a seizure and going into fits... I think his head is going to explode, but that's ok. Use webforms
if you are comfortable and productive with it.
Now, that being said, a few comments. One, the web is not built in an object-oriented manner... it doesn't operate that way. You can build an object-oriented service on the back-end, but the nature of the web is get and post, single stateless transactions.
So, why would you want to build an object-oriented wrapper abstraction on top of it to turn all webpages into objects containing methods and properties? Maybe you would and maybe you wouldn't. Webforms does do that and MVC doesn't. They both work, but I'd
have to side on the people who point out that MVC is really much closer to the real operating model of the web, and webforms is an abstraction that comes with a lot of baggage.
Two, if you think that you need to spread out your interface logic among three classes, inter-twining them and increasing maintenance, then maybe you need to play with the MVC pattern a bit. In the apps that I've been working on, I use a MSCV approach,
utilizing Models, Services, Controllers, and Views. The Models know nothing about the Services, Controllers, or the Views, they are one-hundred percent standalone. I then have a Service tier which consumes the Models, but knows nothing about the Controllers
or the Views. Then I have the Controllers which use the Services, along with the Models definitions, and send data to the Views.
In my version, my models are very dumb objects, mostly just definitions and database mappings. The Controllers are also fairly dumb, and just handle incoming requests for actions, asking the Services what to do, and sending data to the Views as a result.
The Views know only how to render the data sent to them by the Controllers. My Services are the smartest objects in the application, they know everything about my business logic, but as I pointed out before, even they don't know anything about the Controllers
or Views that are higher up the chain. I'm sure other people have slightly different structures and approaches to the MVC pattern, but it is anything but 'highly coupled'. It's sleek, slick, and straight to the point.
You mentioned the NorthwindContext class and mentioned that it was one big table with all the definitions in it. Perhaps, and I could be wrong because I tend to steer clear of anything called Northwind, that you are referring to an auto-generated Linq-to-Sql
data context? If so, yes, those are huge, unwieldy objects. No, it doesn't have to be that way, you can create those mappings yourself in different objects. But no, that has nothing to do with MVC at all.
EDIT: pure.krome: how did you manage to post that while I was writing this... quick fingers! I must be getting old... love the muppet comment. :)
Jul 04, 2008 05:48 AM|LINK
snidersh summed it up very nicely (easily better than my posts).
You mentioned the NorthwindContext class and mentioned that it was one big table with all the definitions in it. Perhaps, and I could be wrong because I tend to steer clear of anything called Northwind, that
you are referring to an auto-generated Linq-to-Sql data context? If so, yes, those are huge, unwieldy objects. No, it doesn't have to be that way, you can create those mappings yourself in different objects. But no, that has nothing to do with MVC at all.
First, let me just say you should feel free to use webforms if you prefer webforms. The MVC community at Microsoft is going to always be dwarfed by the webforms community. If it works for you, don't fix it. Use
webforms if you are comfortable and productive with it.
how did you manage to post that while I was writing this... quick fingers!
Jul 04, 2008 06:09 AM|LINK
I am very happy that I make some fool jump and down and speak nonsense
:-). Oh, it is fun. Anyway, I have seen too many programmers doing doggy things with the company’s money. If you can’t write good code with WebForm, you definitely can’t write code with MVC. Any
way, have fun to be a Beta tester for Microsoft
Jul 04, 2008 06:51 AM|LINK
Correct! In fact ... you should _NOT_ be touching that auto-generated .dbml file at all. DO NOT TOUCH, please. What I do is that I create new files (named after the classes/tables in the dbml file) and make them
partial .. which if you know what partial classes means i'm EXTENDING the class functionality of the existing classes.
Slightly off-topic, but that's what I do as well. Ninety-percent of them end up being empty stubs, but I like seeing them there in the project as a visual list of database entities. I also like to stick enums or constants into them when it's something
simple and I don't need an extra table for it... for instance, a user status of active, inactive, or locked: User.Constants.Status.Locked. That's not something I'd want to define in the Services, since it is a definition of model property states, and I don't
particularly want to make a Status table along with a many-to-many UserStatus table. The Service just has to ask the Model, 'hey, what states can the User.Status property be in?'... and there you have it.
Some people like to be all hard-core and write out all their [Table] mappings for Linq-to-Sql by hand. I thought about that for all of two seconds and realized it gained me nothing at all, because the generated code isn't bloated and I'd basically write
the same thing manually. But I'll never say never, maybe I'll need to do that someday in a project. Maybe in my next webforms application...
This was off-topic, since it's Linq-to-Sql, but I think I can make it serve the topic actually. It's a good example of how I actually appreciate an abstracted concept (ie. the Linq-to-Sql designer) that takes away some work from me. In the same way, I
can appreciate webforms. Back in the day, making a web 'application' was marking up some html and coding up some perl scripts, asp and php came along and was a bit more useful, but when the first asp.net betas came out it was a whole new game and it changed
everything. However, in doing so, it abstracted a lot and brought along a lot of internal baggage. MVC is just a way to get below some, not all, of that abstraction and baggage.
For me, it all boils down to viewstate, postback events, and controls. I don't need viewstate, I'd rather handle requests in a RESTful manner, and I like writing my own html. In fact, I could use webforms and turn off viewstate, never use postback events,
and write all my own html... and many people have been doing that for years. And then we're right back to the an approach that is starting to look an awful lot like MVC, regardless of the specific terminology. All that is different now is that a Microsoft
team is giving us a framework specifically geared for that kind of approach. It's good to have alternatives for people who want them.
Jul 04, 2008 06:05 PM|LINK
Thanks for the feedback. Is there a particular question you wanted to ask or a proposal/suggestion you had in mind?
Sep 26, 2009 12:58 AM|LINK
Harveyliu168, I'm totally with you on every point. Just recently decided to look into what the MVC fuss is about and to my great surprise, it seems like the most idiotic thing I have ever seen in my life. I don't want to go back to the 1980 way of doing
websites. How the hell could you possibly make money working for yourself if you have to write everything from scratch.
If you sitting on your fat ass working for someone, drawing a $100K check and have the luxury to do things in such a nonesensical and backward way, you have no clients and don't care about wasting someone's time and hard earned money then MVC is for you!
On the other hand if you are actually earning a living then you need the tools to get the job done yesterday and hopefully enjoy your work while you doing it.
Who the hell came up with this absurdity (MVC)? What moron would think that going back to the way back machine is a good idea and what even bigger moron said that it was ok a good? All for what? Cleaner code output? Fractionally better performance? You want
me to work like this so I can have better HTML output? Who buys into this crap? Someone has too much time on their hand I say.
WebForms are a mature, tried and tested platform. Why not invest the time, money and effort into fixing what we have instead of wasting so much time and resources on yet another stupid useless crap for brainwashed purist?
17 years in this business and I have never ones seen any true innovation in web development outside of drag and drop. Long live drag and drop! - the best idea ever in web development history. How can I possibly stay in business doing even the most mundane
things from scratch? My clients want everything for FREE and want it done yesterday... Is this supposed to help me???
I say fix the problems with WebForms, give us clean code output, much more drag-and-drop components for real life every-day development also with clean and correct code output that work efficiently and flawlessly.
Why is it that people working in their grandmother's garage can always find a way to innovate and come up with better stuff then a big company like Microsoft can? When will the politics end and common sense begin???
ASP.Net is an amazing framework and I absolutelly love it but for ones I'd like to see something new that actually helps me as a hard working individual who has to earn every friking penny. Today every Joe Shmoe, Tom, Dick and Harry is either a web developer
or a big software corporation taking business away from the little guy who just wants to make a living.
We need the tools that allow us to stay in business, get the job done in the
shortest possible time, get paid and then move the hell on to the next project. Why is this so hard to understand??? I'm not an artist stroking the canvas for the next ten years nor do I get a bailout to pay my bills.
Like I always say, show me the smartest, most brilliant f***er in the world and I show you how he or she can't even tie their f***ing shoes! Its not about how much useless random crap you can memorize and how great code you can write but about being able
to think about the world in a way that does not put you in the center of it.
Sep 26, 2009 02:53 AM|LINK
have you you read Rob Conery's "I Spose I’ll Just Say It: You Should Learn MVC"
Let me address your points:
1. over complicated ~~ I might call it over simplified ~~ raw, like HTML
yes, a lot of behind the scenes happens but in many ways
it is more open than some third party WebForm control ... bonus ++
== you get the source code too!!
2. ASP.NET MVC can handle more UIs that WebForms ... at present you
may have to do a lot of your own wiring ... but give ASP.NET MVC a
break ... it's only been a product since March 18th of this year.
3. F11, F11, F11 .... plus you've access to the source code.
4. Stateless == REST == the real Internet paradigm
whereas WebForms hid that reality from developers.
5. Any control from WebForms will have its REST equivalent in ASP.NET MVC;
ASP.NET MVC controls will be unit testable. See codeplex:
There is quite a lot happening at http://www.codeplex.com/:
returns 420 projects.
If you exclude projects "still in development" you get 65.
You'll find support for JSON and AJAX too.
(via Google: asp.net mvc JSON)
(via Google: asp.net mvc ajax)
http://www.nikhilk.net/Ajax-MVC.aspx <=== check this out
While you are at, also check out Script#:
How is ASP.NET MVC unfriendly with css?