I seen this and I downloaded it earlier this week, it wouldn't build straight off, there were bugs in the script references, also EntityFramework 4.1 wouldn't resolve for me locally (had to add web.config ) , etc, not a great start (no biggie, just saying). Resolved these issues anyhow.

On review, its fair enough if you love ASP.NET MVC, but I really don't like the mixing of the View Logic with the Model in ASP.NET MVC, like I already said keep it clean. From a View point of view keep it decoupled I say, keep any server side code out of there. At the end of the day , I have to agree ASP.NET MVC has got rich resources and it is a great offering for developers, no doubt.

And MVC 4 useS knockout js behind the scenes anyhow, which is really great and personally I think that knockout goes far enough.

The only reason I say this, is because I just refactored about 20 Web Form Views to pure HTML/CSS/js on the client side and turned out I had no need for any server side at all except for the restful service (hidden away in my knockout view model, used amplify.js to abstract the service calls) created on top of my domain model. so I am thinking, why do I need MVC if I have Restful WCF/ ASP.NET Web API. Going this way means I am totally decoupled!

I am much happier building a restful service, knowing that any client can consume this, and I think I am happy building client side anyway that I so choose and not tying myself into ASP.NET MVC unnecessarily.

So here's the deal for me if go pure W3C on the client :

1. No mixing in logic

2. Don't care about the server or server side code.

3. I can mock my backend real easy ( e.g. Amplify.js )

4. I don't need Visual Studio for client side dev.

5. There's a growing wealth of open source libraries

6. Makes me think more about the structure of my server side behavioural domain model.

Anyways, just how I see things..always open to more compelling arguments!

Can you expand more on "the mixing of the View Logic with the Model in ASP.NET MVC" – I must have missed a trick in how to further separate concerns.I favour strongly typed views, ViewModels and thin controllers. But are you talking about how the generated HTML is just output, and contains both page structure and page data?

Also with this release of MVC, the Restful data controllers are added on the side. Designing this from scratch, it would probably be different – if your client wants JSON, XML or some other format, then the Data endpoint is for you. If you want text/html, then it's special and you go somewhere else.

We can already serve JSON or XML data off controller endpoints in MVC3, and using a bit of extra code, even switch between them by checking the Accept header. But never mind, it's not done until it's in the framework.

If you really are past using MVC views entirely, and have just pages without server-side markup (except perhaps feeding in data URL) + a rest API then you are an outlier and can consider other fameworks beside MVC, such as OpenRasta. Or Ruby.

MVC is not an opinionated framework – you can do things any number of ways. If it supports Data API + static HTML websites, which it looks like, that will not be the only thing that it supports.

I am not past anything, I am just saying this paradigm is now kinda defunct to me. I would prefer to work a little differently.

No doubt MVC facilitates all of the above, if you favour strongly typed, then that's good, continue that way, but its not necessary ( controller is now basically going to be a restful web service )

"We can already serve JSON or XML data off controller endpoints in MVC3" - true, and you'll probably be using Web API to do that soon.

I am just saying its not necessary to mix, I feel it over complicates the client by making you mix serverside logic a la razor, webform whatever.

I don't particlarly see the point in it now though. If you look for example at the knockout mapping plugin for knockout js, it will take a json source and automatically resolve into your js viewmodel. so on the client all I am doing is thinking about the client. give me a rest api and some json objects and I am off and running.

All I am simply saying, Pure Html/CSS/JS can be done without the need for any knowledge of the server on client side, just the interface contract and like I say a restful wcf service / Web API is good.

I am not an "out lier" when I say I think its a good way to develop, its my opinion. The truth is, I did refactor a load of "webforms" lately and the result was,

1. Html/Js/css - knockout.js and amplify.js

2. JSON Service ( c# in behind serving the data and validating business rules )

> "We can already serve JSON or XML data off controller endpoints in MVC3" - true, and you'll probably be using Web API to do that soon.

Yes, I will as soon as I'm on a released version of ASP MVC 4. I get that format flexibility at no extra cost using no custom or server-side code. Win. It enforces the separation of concerns between serving html pages and serving API data. Which may or may not be good depending on how you think about your App. For my existing apps I think it's positive.

ASP MVC is a framework that is not opinionated as I said - it won't insist on doing things the right way, and it is also a framework that is not innovative. Most or all features have been pioneered and proven elsewhere. I'm not saying that as an insult, there are big upsides to that approach and I can see why MS stays in the mainstream.

> I am not an "out lier"

No disrespect intended. I meant to say that you're well ahead of the ASP.NET pack. Many of them are still making webforms, never mind getting over MVC or even experimenting with various ways of doing things that have not yet been blessed by Microsoft.