Luis,
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
opening thread.
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.
:: Never underestimate the predictability of stupidity ::
I am very glad that I started this heated topic and I am proud of myself be so brave. :)Anyway, why WebForm is good? The answer
is it follows the OO principles ant that is you put method and data related into one class. You have one page and one page behind and you use event handling which best suit user integrations. 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? 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. But still MS has the ability to make the ViewState much much smaller footprint and put it on the server side from the very beginning. This is what MS should focus on, to improve what they
got now and to improve what they are good at. I don't know since when MVC become the "Standard". MVC is just one design pattern which among thousands. And if you try to use one pattern for all scenarios you will always end up trouble. As these kind of over
simplified approach never work well and you have to do the hacking and tricks all the time.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. 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. I think MS has done a wonderful job to wrapper the html tags with a class. And this is what programmer always thinking, class, object, interface and patterns. HTML is not for programmers,
it is for school kids who know nothing about programming.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? 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??? Every
time, when somebody proposes a framework that requires I write everything by myself, I will walk away. As the golden rule of software development is REUSE, REUSE and REUSE.Talking about
Postbacks, yes it doesn’t work all the time. Suppose you have a very fat page, the postback will take quite long time. But you can always use Ajax to workaround in such situation. It is fair to say that the postback works more than 80% of the time and the
development time it saved is heaps.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.
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.
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
Same with MVC. (sigh)
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
This is standard nTier programming... which most people don't really follow to a letter. Don't blame the framework, blame the user. That said, this still applies to MVC. Someone above posted this, above.
Why do you need put your UI logic in 3 separted class, the view, the model, the controller
Because you're a muppet if you do and don't understand MVC properly. The View is the html front end. it's EXACTLY that.. U.I.
A view is a visual representation of some data. Nothing more. By the time you 'get to the view' ... you should have figured out all the data that is required. Now, with webforms ... the .aspx is technically the view but in effect people are mixing
the code behind with logic to determine what to show. This logic is _toughtly coupled_ to the (webform) view, IMO. It's as simple as that. aspx == front. aspx.cs == code behind for the aspx page. With this in mind, you can't use that logic anywhere else. So
then you say, that should go into the BAL. Things aren't as simple as that in the real world. In summary, the MVC model of specifing a controller to handle USER ACTIONS/REQUESTS clearly (IMO) seperates the logic into reusable parts. Moreso, the views are now
completly independant of any actions. They are exactly what they should be -> dumb, simple, must-only-display-this-html. No smarts at all. KISS. (note to the advanced: having a foreach code in the view is 100% acceptable becuase it's directly related to how
the data on that view is being displayed .. it's not a business logic thing, etc).
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.
Bzzzzt. (refer to the two paragraphs above, please).
I totally agree that ViewState need improvement, because it is unnecessarily
huge. Thankfully I can put the ViewState in memory on the server side
Winnah! That's the solution .. i aggr..... ack! i can't type it.. OK. what's wrong with the statement. It's true that the viewstate is huge - so kewl, we're not arguing over that. So lets throw it on the server? this reaks of a few things :-
1) Band-aid solution on a band-aid problem? (eg. mistake on mistake on mistake, etc..)
2) You think viewstates are a good thing
3) You don't understand the concept of having a lean and tight application because you're blinded by false information that loosing all these drag and drop objects == more work to do (I'll talk more on this below, when i get to those quotes from you
4) You're caught up with trying to have a stateFULL web application in a stateLESS environment (also, more on this below when i get those quotes too).
5) You think viewstates are a good thing ... still.
6) You don't have a proper understanding of web technologies IMO shown through your wishlist of items compared to the environment you're playing in.
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".
It did? Damn! i missed that one. Pics or it didn't happen.
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?
This is a beauty. :) I'm not sure where to start with this. In fact, i don't think i can :( there's too much i could say. Maybe i'll prolly say ask the question 'what's wrong with css and html not being OO or anti-OO (typo fixed) as you asserted?' I don't get
it? I think what you've said highlights how u've been sucking at the dumbing-down-teet for far too long and are drunk on dumbification. By simplifying things too much, you suddenly restrict your usability. You ask why they don't have a textbox or radio box,
etc.. Er.. they do? the asp controls you're addicted too are just wrappers for those. The html spec has be powerful enough to allow users to visualise their data with a lot of freedom. Now, it's been around a while and there are other successors in the pipelines
(WPF maybe?) trying to take some of that space .. but what you are asking is not for something simplier, but something that you are used to. Put it this way, when i did my first mvc project at the end of last year, the first thing i wanted to do was
a textbox. I EVEN SAID THAT. Fail :( That's how dumbed down i was. I was using an environment and i wasn't even using the correct terms ... highlighting how much i had removed myself from the technology that was my bread and butter of my existence. I should
have said, 'how do i to an text input item. I actually had to think .. what is this technology (html) that i'm using and how do i use it .. again? You're scared of change and either don't understand what tool you are using or have forgotton.
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.
Er .. you can. I don't get it. That's what css is about .. styling visual placeholders/items. This weird statement also has nothing to do with webforms or mvc.
And this is what programmer always thinking, class, object, interface and patterns
heh .. dude .. you're really digging your own hole here :( What about performance, maintainability, reuse, tdd, etc.. or does that all get summarised as patterns? *sigh*
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?
Now we're getting somewhere! You go girl! Get those big guns out and firing! Did you know MVC also doesn't work with php code and my some cobol i saw rotting in the corner? Oh.... so just because you still sucking on the teet of control-dumbification and that
if it's .NET it has to 100% work with MVC ... but it's not .. suddenly the product is teh-fail (sic) ? bzzzt. You're trying to say that because something was working with one technolgy (and mind you .. all those items were only created against that technology)
will work with another? nope. I can understand your frustration with having spent a lot of time skilling up yourself with an aresenal of tools, tricks and tips ... only to find that the majority of things in that aresenal are now not working in the MVC world?
That would suck big time! Maybe i was lucky with the fact that i put very little faith in controls because the majority of the time html was far sufficent for the multiple projects i've been working on. I chortle when i hear people live and die by their addiction
of the GridView :) I think the only real control that we've ever had to rely on in all the web projects we've done (and no, they're not uni hello world northwind thingies) has been the calendar control. Anyways, the main answer to your statement is that the
product is BETA. The developers are working on releasing the product so that MS Ajax will work with it. Currently, i've been using jQuery to handle all my ajax is the stomps. Even when MS Ajax works with MVC, i'll not migrate to it. jQuery is just so hawt.
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
something.
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???
MVC View User Controls, Master pages and input fields. If you really want, u can use HtmlHelpers that come with MVC .. they are sorta like asp controls.. except they are not drop and drag stuff (just yet?) and are wrappers to html - just like controls. Except
they are light and lean -- think of them as shorthand for html.
For myself, I could prolly do it a bit slower than your control way .. initially .. but in the long term I'd think id find the solution more elegant with things sperated nicely, etc. It's such an open question. Everyone can polish a turd differently .. but
it could still be turd. You might get your UI up quicker than me, but i could prolly catch up with the business logic? who knows. maybe you're so good that we'll never be able to compete (we're competing now?).
(loose quote). blah blah blah. Use Ajax to speed up page loads cause viewstate sucks. blah blah more postback blah blah
Over this.
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!
Sure is .. and that's how it should be IMO. You're trying to stick a triangle block into a square hole from my son's play-toy-thingy(tm). bzzzzt #3. The web is stateless. Therefore, embrace it. Hug it. Buy a VW beetle and get all hippe loved up on the stateless
web framework. The power of the web is the fact that it _IS_ stateless. This means the least amount of data gets thrown around a limited medium. It really really really shows that you're a desktop application developer (which is totally kewl) but you're trying
to brind concepts into a different environment. It's the same when i do desktop apps ... i know it's stateful so i use different concepts that evolve around stateful programming. If you think having webforms means web == stateful? then i think you're wrong.
It's fluff to help those take up web programming quicker and easier ... at a serious cost when it comes to semi-serious <-> serious projects. I completly disagree with your assertion about
'challenge of web development is to make the stateless HTTP state aware'. There's no challenge for me what-so-ever .. and both MVC and webforms allow you to handle this stateless enviroment perfectly fine .. as do RoR, etc.. I think you're misguided
with what you're trying to achieve because you're not open to other methods that can achieve the same result(s), just in a different way.
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.
In fact, you've highlighted many times you don't understand the reasons ... and even your statement at the end of that sentence highlights the fact you really are missing the point of ASP.NET MVC.
Traditionally, the MVC idea was that you can have a single model and a single controller layer .. and substitute any view engine in there. View engines could be aimed at the WEB or the DESKTOP (WIN) or ... any visual medium (mobile phone, my watch lcd .. whatever).
By having a single business and data tier (trying to poorly connect mvc to 3tier .. which is not necessarily a wise thing to do) but multiple views means you don't have to repeat many parts of the work load ... Now, ASP.NET is _NOT_ this and they've stated
that many times. It's aimed at the web only. There
is no unified architecture for web apps. it's an OPTION for web developers. Maybe you're getting the tradition concept a wee bit mixed up with something?
..
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.
Webforms might seem like a low cost initially, but it also has a high support / maintence cost as the project life matures. Either i've been around too many poor programmers and i myself and the king of crap or ... maybe .. just maybe ... there are poor developers
doing poor development because their toolset is doing poor things for them .. speed at the cost of support/performance/maintainability/tdd (this one ALWAYS get's forgotton). I love how you're soo pro-RAD / pro-speed developement .. we could start a new type
of developer attitude. Instead of speed dating, we have speed dev'ing. Screw what happens after we get to the goal .. lets just get there asap. Cause no project needs support and maintenence .. hells no :) Testing? meh! i'm the LordOfTesting(tm). Bugs pheer
my quick turnaround.
Summary 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.
:: Never underestimate the predictability of stupidity ::
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. :)
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.
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. But most importantly, that's nothing to do with MVC or WebForms -- it's a Linq2Sql thing .. and if u don't like that, then start a fail thread in their sub-forum (or ask nicely some questions
about why the team have done what they've done).
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.
Bingo! It's a tried and tested product and it's works great. It's ok to stick with it. The MVC community are NOT trying to say mvc is better than webforms. If anything, they are constantly trying to say that it's another way to do things .. it's not better
or worse. It's just like in the old days people trying to say c# is better than vb.net (oooooo i'm tempted to flog that dead horse one more time :) c# ftw!) .. they both get you to the same end-goal, just in a different way.
how did you manage to post that while I was writing this... quick fingers!
I lost over an hour of my life i'll never ever get back :( RSI snidersh ? >:) /me ducks and hides.
:: Never underestimate the predictability of stupidity ::
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 :-).
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.
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.
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:
B-) Please help me by completing my school survey about computer programmers on my website. Thank you!!! Gerry Lowry +1 705-429-7550 wasaga beach, ontario, canada
pure.krome
Member
532 Points
349 Posts
Re: MVC sucks
Jul 04, 2008 12:07 AM|LINK
Luis,
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 opening thread.
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.
harveyliu168
Member
40 Points
14 Posts
Re: MVC sucks
Jul 04, 2008 02:18 AM|LINK
I am very glad that I started this heated topic and I am proud of myself be so brave. :)Anyway, why WebForm is good? The answer is it follows the OO principles ant that is you put method and data related into one class. You have one page and one page behind and you use event handling which best suit user integrations. 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? 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. But still MS has the ability to make the ViewState much much smaller footprint and put it on the server side from the very beginning. This is what MS should focus on, to improve what they got now and to improve what they are good at. I don't know since when MVC become the "Standard". MVC is just one design pattern which among thousands. And if you try to use one pattern for all scenarios you will always end up trouble. As these kind of over simplified approach never work well and you have to do the hacking and tricks all the time.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. 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. I think MS has done a wonderful job to wrapper the html tags with a class. And this is what programmer always thinking, class, object, interface and patterns. HTML is not for programmers, it is for school kids who know nothing about programming.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? 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??? Every time, when somebody proposes a framework that requires I write everything by myself, I will walk away. As the golden rule of software development is REUSE, REUSE and REUSE.Talking about Postbacks, yes it doesn’t work all the time. Suppose you have a very fat page, the postback will take quite long time. But you can always use Ajax to workaround in such situation. It is fair to say that the postback works more than 80% of the time and the development time it saved is heaps.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. 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.
pure.krome
Member
532 Points
349 Posts
Re: MVC sucks
Jul 04, 2008 04:24 AM|LINK
Wall.Of.Text part ][
/me cries.
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 ???
Same with MVC. (sigh)
This is standard nTier programming... which most people don't really follow to a letter. Don't blame the framework, blame the user. That said, this still applies to MVC. Someone above posted this, above.
Because you're a muppet if you do and don't understand MVC properly. The View is the html front end. it's EXACTLY that.. U.I. A view is a visual representation of some data. Nothing more. By the time you 'get to the view' ... you should have figured out all the data that is required. Now, with webforms ... the .aspx is technically the view but in effect people are mixing the code behind with logic to determine what to show. This logic is _toughtly coupled_ to the (webform) view, IMO. It's as simple as that. aspx == front. aspx.cs == code behind for the aspx page. With this in mind, you can't use that logic anywhere else. So then you say, that should go into the BAL. Things aren't as simple as that in the real world. In summary, the MVC model of specifing a controller to handle USER ACTIONS/REQUESTS clearly (IMO) seperates the logic into reusable parts. Moreso, the views are now completly independant of any actions. They are exactly what they should be -> dumb, simple, must-only-display-this-html. No smarts at all. KISS. (note to the advanced: having a foreach code in the view is 100% acceptable becuase it's directly related to how the data on that view is being displayed .. it's not a business logic thing, etc).
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.
Bzzzzt. (refer to the two paragraphs above, please).
Winnah! That's the solution .. i aggr..... ack! i can't type it.. OK. what's wrong with the statement. It's true that the viewstate is huge - so kewl, we're not arguing over that. So lets throw it on the server? this reaks of a few things :-
1) Band-aid solution on a band-aid problem? (eg. mistake on mistake on mistake, etc..)
2) You think viewstates are a good thing
3) You don't understand the concept of having a lean and tight application because you're blinded by false information that loosing all these drag and drop objects == more work to do (I'll talk more on this below, when i get to those quotes from you
4) You're caught up with trying to have a stateFULL web application in a stateLESS environment (also, more on this below when i get those quotes too).
5) You think viewstates are a good thing ... still.
6) You don't have a proper understanding of web technologies IMO shown through your wishlist of items compared to the environment you're playing in.
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 :(
It did? Damn! i missed that one. Pics or it didn't happen.
Oh, this is good :) Ok .. so the HTML spec sucks .. so dude .. do use it. Actually, lets sorta diverge a bit here. If I understand you right, you're saying that u don't like visualising websites using HTML? Or .. should i put it in an MVC way .. u don't like to visualise your web sites using the HTML View Engine? No probs (oh .. this is so good, i can taste the sweet joy on my lips)) ... swap out the HTML view engine and replace it with another one .. like .. hmm..
o) 4 different views found in the MVCContrib project: http://www.codeplex.com/MVCContrib
o) Read about the 4 views here: http://codebetter.com/blogs/jeffrey.palermo/archive/2008/01/27/mvccontrib-now-offers-four-4-alternative-view-engines-for-asp-net-mvc.aspx
o) Read about NHaml View Engine (1 of those views) here: http://andrewpeters.net/2007/12/19/introducing-nhaml-an-aspnet-mvc-view-engine/
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!
This is a beauty. :) I'm not sure where to start with this. In fact, i don't think i can :( there's too much i could say. Maybe i'll prolly say ask the question 'what's wrong with css and html not being OO or anti-OO (typo fixed) as you asserted?' I don't get it? I think what you've said highlights how u've been sucking at the dumbing-down-teet for far too long and are drunk on dumbification. By simplifying things too much, you suddenly restrict your usability. You ask why they don't have a textbox or radio box, etc.. Er.. they do? the asp controls you're addicted too are just wrappers for those. The html spec has be powerful enough to allow users to visualise their data with a lot of freedom. Now, it's been around a while and there are other successors in the pipelines (WPF maybe?) trying to take some of that space .. but what you are asking is not for something simplier, but something that you are used to. Put it this way, when i did my first mvc project at the end of last year, the first thing i wanted to do was a textbox. I EVEN SAID THAT. Fail :( That's how dumbed down i was. I was using an environment and i wasn't even using the correct terms ... highlighting how much i had removed myself from the technology that was my bread and butter of my existence. I should have said, 'how do i to an text input item. I actually had to think .. what is this technology (html) that i'm using and how do i use it .. again? You're scared of change and either don't understand what tool you are using or have forgotton.
Er .. you can. I don't get it. That's what css is about .. styling visual placeholders/items. This weird statement also has nothing to do with webforms or mvc.
heh .. dude .. you're really digging your own hole here :( What about performance, maintainability, reuse, tdd, etc.. or does that all get summarised as patterns? *sigh*
Now we're getting somewhere! You go girl! Get those big guns out and firing! Did you know MVC also doesn't work with php code and my some cobol i saw rotting in the corner? Oh.... so just because you still sucking on the teet of control-dumbification and that if it's .NET it has to 100% work with MVC ... but it's not .. suddenly the product is teh-fail (sic) ? bzzzt. You're trying to say that because something was working with one technolgy (and mind you .. all those items were only created against that technology) will work with another? nope. I can understand your frustration with having spent a lot of time skilling up yourself with an aresenal of tools, tricks and tips ... only to find that the majority of things in that aresenal are now not working in the MVC world? That would suck big time! Maybe i was lucky with the fact that i put very little faith in controls because the majority of the time html was far sufficent for the multiple projects i've been working on. I chortle when i hear people live and die by their addiction of the GridView :) I think the only real control that we've ever had to rely on in all the web projects we've done (and no, they're not uni hello world northwind thingies) has been the calendar control. Anyways, the main answer to your statement is that the product is BETA. The developers are working on releasing the product so that MS Ajax will work with it. Currently, i've been using jQuery to handle all my ajax is the stomps. Even when MS Ajax works with MVC, i'll not migrate to it. jQuery is just so hawt.
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 something.
Hmm.. why am i still replying? Too late now .. must... continue.
MVC View User Controls, Master pages and input fields. If you really want, u can use HtmlHelpers that come with MVC .. they are sorta like asp controls.. except they are not drop and drag stuff (just yet?) and are wrappers to html - just like controls. Except they are light and lean -- think of them as shorthand for html.
For myself, I could prolly do it a bit slower than your control way .. initially .. but in the long term I'd think id find the solution more elegant with things sperated nicely, etc. It's such an open question. Everyone can polish a turd differently .. but it could still be turd. You might get your UI up quicker than me, but i could prolly catch up with the business logic? who knows. maybe you're so good that we'll never be able to compete (we're competing now?).
Over this.
Sure is .. and that's how it should be IMO. You're trying to stick a triangle block into a square hole from my son's play-toy-thingy(tm). bzzzzt #3. The web is stateless. Therefore, embrace it. Hug it. Buy a VW beetle and get all hippe loved up on the stateless web framework. The power of the web is the fact that it _IS_ stateless. This means the least amount of data gets thrown around a limited medium. It really really really shows that you're a desktop application developer (which is totally kewl) but you're trying to brind concepts into a different environment. It's the same when i do desktop apps ... i know it's stateful so i use different concepts that evolve around stateful programming. If you think having webforms means web == stateful? then i think you're wrong. It's fluff to help those take up web programming quicker and easier ... at a serious cost when it comes to semi-serious <-> serious projects. I completly disagree with your assertion about 'challenge of web development is to make the stateless HTTP state aware'. There's no challenge for me what-so-ever .. and both MVC and webforms allow you to handle this stateless enviroment perfectly fine .. as do RoR, etc.. I think you're misguided with what you're trying to achieve because you're not open to other methods that can achieve the same result(s), just in a different way.
In fact, you've highlighted many times you don't understand the reasons ... and even your statement at the end of that sentence highlights the fact you really are missing the point of ASP.NET MVC.
Traditionally, the MVC idea was that you can have a single model and a single controller layer .. and substitute any view engine in there. View engines could be aimed at the WEB or the DESKTOP (WIN) or ... any visual medium (mobile phone, my watch lcd .. whatever). By having a single business and data tier (trying to poorly connect mvc to 3tier .. which is not necessarily a wise thing to do) but multiple views means you don't have to repeat many parts of the work load ... Now, ASP.NET is _NOT_ this and they've stated that many times. It's aimed at the web only. There is no unified architecture for web apps. it's an OPTION for web developers. Maybe you're getting the tradition concept a wee bit mixed up with something?
.. nearly there ... well done for reading this far, reader!
Webforms might seem like a low cost initially, but it also has a high support / maintence cost as the project life matures. Either i've been around too many poor programmers and i myself and the king of crap or ... maybe .. just maybe ... there are poor developers doing poor development because their toolset is doing poor things for them .. speed at the cost of support/performance/maintainability/tdd (this one ALWAYS get's forgotton). I love how you're soo pro-RAD / pro-speed developement .. we could start a new type of developer attitude. Instead of speed dating, we have speed dev'ing. Screw what happens after we get to the goal .. lets just get there asap. Cause no project needs support and maintenence .. hells no :) Testing? meh! i'm the LordOfTesting(tm). Bugs pheer my quick turnaround.
Summary
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.
snidersh
Member
75 Points
29 Posts
Re: MVC sucks
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. :)
pure.krome
Member
532 Points
349 Posts
Re: MVC sucks
Jul 04, 2008 05:48 AM|LINK
snidersh summed it up very nicely (easily better than my posts).
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. But most importantly, that's nothing to do with MVC or WebForms -- it's a Linq2Sql thing .. and if u don't like that, then start a fail thread in their sub-forum (or ask nicely some questions about why the team have done what they've done).
Bingo! It's a tried and tested product and it's works great. It's ok to stick with it. The MVC community are NOT trying to say mvc is better than webforms. If anything, they are constantly trying to say that it's another way to do things .. it's not better or worse. It's just like in the old days people trying to say c# is better than vb.net (oooooo i'm tempted to flog that dead horse one more time :) c# ftw!) .. they both get you to the same end-goal, just in a different way.
I lost over an hour of my life i'll never ever get back :( RSI snidersh ? >:) /me ducks and hides.
harveyliu168
Member
40 Points
14 Posts
Re: MVC sucks
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 :-).
snidersh
Member
75 Points
29 Posts
Re: MVC sucks
Jul 04, 2008 06:51 AM|LINK
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.
Haacked
Contributor
6901 Points
412 Posts
Re: MVC sucks
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?
Senior Program Manager, Microsoft
What wouldn’t you do for a Klondike bar?
saburius
Member
139 Points
249 Posts
Re: MVC sucks
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.
gerrylowry
All-Star
20513 Points
5712 Posts
Re: MVC sucks
Sep 26, 2009 02:53 AM|LINK
@ harveyliu168
have you you read Rob Conery's "I Spose I’ll Just Say It: You Should Learn MVC"
at http://blog.wekeroad.com/blog/i-spose-ill-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/:
http://www.codeplex.com/site/search?projectSearchText=MVC
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#:
http://projects.nikhilk.net/
How is ASP.NET MVC unfriendly with css?
Regards,
Gerry (Lowry)