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.
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.
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.