Source
Let's be clear, ASP.NET MVC is an improvement over WebForms - and those developers refusing to leverage ASP.NET MVC (or something else) for new projects are simply lazy. WebForms is full of leaky abstraction, really tight coupling, and ridiculous concepts - such as viewstates and postbacks.
Being able to write complex systems more cleanly is a good start, but given where web development stands in general, and other platforms specifically, ASP.NET MVC lags far behind (Perl being the only one I can think of which is worse).
There's little question that a big part of the problem is that this is really a VC stack - there is no thought, no support, and no tools for the Model. When you compare the thousands of lines you'll end up writing for your repository/dal/linq/nhiberate to other MVC stacks (which commonly only require that your models to inherit from 1 class), you're already at a serious productivity disadvantage. But the true impact is actually much worse - you lose any cohesiveness of purpose through the controller and views. There is no way to generate HTML labels from model properties, or client side validation. In frameworks such as Akelos, RoR or Django everything flows outwards from the model which allows those frameworks to provide cohesive and integrated tools, not just HtmlHelpers, ActionResults and Routing (which is all you get from ASP.NET MVC).
You end up having to do a whole lot of plumbing on both sides of your system.
Monday, April 27, 2009
Friday, April 24, 2009
How we do MVC
Source
Like many of the frameworks coming out of Redmond, MVC is not an opinionated framework. Rather, it is a framework that enables you to form your own opinions (good or bad). It’s taken quite a long way, with a very stable result at the end. It’s certainly not perfect, and there are a few directions we’d like to go differently given the chance. In the next few posts, I’ll elaborate with real examples on the big examples here, otherwise, I’d love to have people poke holes in our approach
Like many of the frameworks coming out of Redmond, MVC is not an opinionated framework. Rather, it is a framework that enables you to form your own opinions (good or bad). It’s taken quite a long way, with a very stable result at the end. It’s certainly not perfect, and there are a few directions we’d like to go differently given the chance. In the next few posts, I’ll elaborate with real examples on the big examples here, otherwise, I’d love to have people poke holes in our approach
Thursday, April 23, 2009
You Should Learn MVC (with 3 reasons)
Source
1 – Testability. No – not talking about the TDD variety, just testing in general. If you’re “not a testing person” that’s OK – the rest of the computer science world has embraced the idea that “testing what we build is a pretty good idea”. You don’t really want your clients to catch that silly “InvalidCastException” do ya? There’s LOTS of reasons to want to test – again not TDD – just good old Unit Testing! It’s easy peasy with MVC and this alone should pull you in to at least check it out – along with why testing can save you time and money.
2 – Control over HTML. I’m sure you’ve heard this before – mangled ID’s, non-validating HTML, etc. Why is this important? Because you might want to use client-side programming for something! I won’t bang this gong for too long – but it’s a lot more than “making ViewSource look pretty” – you’re communicating with super-finicky creatures (browsers) that love to argue – being able to smith the markup experience makes you a more valuable developer!
3 – Extensibility. Literally every part of MVC Is pluggable – and in the last 3 apps I wrote (Storefront, Nerddinner, and SubSonic’s MVC Starter) I used my own ViewEngine to save some time and work. I’ve spun up my own ControllerFactory so I can use IoC (which is awesome fun!) Understanding this is the keys to the kingdom for any developer! Have you ever been freaked out because you needed to use Page_PreRender to get something to load into the ControlTree properly so it will show when you need it to? MVC does not lock you into anything – you’re free to do what you want to.
1 – Testability. No – not talking about the TDD variety, just testing in general. If you’re “not a testing person” that’s OK – the rest of the computer science world has embraced the idea that “testing what we build is a pretty good idea”. You don’t really want your clients to catch that silly “InvalidCastException” do ya? There’s LOTS of reasons to want to test – again not TDD – just good old Unit Testing! It’s easy peasy with MVC and this alone should pull you in to at least check it out – along with why testing can save you time and money.
2 – Control over HTML. I’m sure you’ve heard this before – mangled ID’s, non-validating HTML, etc. Why is this important? Because you might want to use client-side programming for something! I won’t bang this gong for too long – but it’s a lot more than “making ViewSource look pretty” – you’re communicating with super-finicky creatures (browsers) that love to argue – being able to smith the markup experience makes you a more valuable developer!
3 – Extensibility. Literally every part of MVC Is pluggable – and in the last 3 apps I wrote (Storefront, Nerddinner, and SubSonic’s MVC Starter) I used my own ViewEngine to save some time and work. I’ve spun up my own ControllerFactory so I can use IoC (which is awesome fun!) Understanding this is the keys to the kingdom for any developer! Have you ever been freaked out because you needed to use Page_PreRender to get something to load into the ControlTree properly so it will show when you need it to? MVC does not lock you into anything – you’re free to do what you want to.
Wednesday, April 22, 2009
Basic Selectors in JQuery
1. By the ID attribute.
If the ID contains special character then you can escape them with backslashes. For example to find a text box with ID txtName you can write the following :
$("#txtName")
Then you can do any operation on the text box like getting the value or changing the css class.
2. By given element name. For example to get all the DIV elements following is the syntax
$("div")
This will find all the DIVs present in the page. You can do any operation after that.
3. By given class name. The following code finds all the elements which have class name 'RedButton'.
$(".RedButton")
Source
If the ID contains special character then you can escape them with backslashes. For example to find a text box with ID txtName you can write the following :
$("#txtName")
Then you can do any operation on the text box like getting the value or changing the css class.
2. By given element name. For example to get all the DIV elements following is the syntax
$("div")
This will find all the DIVs present in the page. You can do any operation after that.
3. By given class name. The following code finds all the elements which have class name 'RedButton'.
$(".RedButton")
Source
Subscribe to:
Posts (Atom)