Given the roadmap there, I'd say that the wait won't be terribly long. I have been very impressed with the turnaround times on new versions of MVC so far.
The feature that seems most likely to cause issues with a release would be Recipes because of their connection to NuGet. I'd expect to see a pretty feature complete CTP without that first, with the complete implementation being spread across one or two more.
I have no inside line on this, but I've been working with it since v1 so I follow it pretty closely.
I thought it had been re-branded as BUILD this year (and was going to have a massive Windows 8 focus). I've seen some reports of "PDC 2011" but then the dates and location are the same as build....unless they're going to run to conferences concurrently, which I doubt.
Correct. There is no separate PDC this year. The focus of Build at least in the promotion is definitely on Windows 8, who knows to what extent that reflects the content.
MVC3 has always been extensible enough so you could add most of the major new features in the MVC4 roadmap. The "extra mile" polish you would normally add to MVC3 applications look like they will be in MVC4 as standard:
* jQuery Mobile templates
* Mobile/Desktop view switch API
* EF Code First DB Migrations (finally, without having to rely on third party libraries such as MigratorDotNet)
* Built-in JavaScript and CSS minimization
I wonder if this is going to push the NH guys to do an official migrations package. You can already come pretty close to it just using the schema migration APIs, so they have a lot of the pieces. I'd love to see some competition in what I think is historically an under-addressed part of development on any given Microsoft stack.
Our LightSpeed ORM product does schema migrations between a whole pile of databases and includes Visual Studio 2008 & 2010 integration for seeing the migrations, executing them, generating the SQL files etc.
I haven't seen anyone else really pushing Migrations that hard yet in the .NET space. Would be nice to see others trying to improve this space.
Interesting, I've never heard of LightSpeed. I'll be honest that I have a near-zero level of trust for this type of software from vendors in the .NET space, but I'll definitely give it a look.
Code-generation has always been a major annoyance for real (ya, I said it) developers using MS tools. It'll be interesting to see if recipes are able to do what decades of similar promises from MS have failed to deliver.
The mention of a recipe for an AJAX grid is frightening though...like we are heading back into server-control world. Despite all the talk, MS never really bought into jQuery.
Also, I worry when the 2nd feature listed is that the default CSS/theme (which no one uses and is pretty ugly) supports mobile devices.
They mention deployment as a theme, but no feature to accompany it. It'll be interesting to see what they manage to do here. It's certainly a major pain point right now.
Of course, none of this addresses the primary issues with ASP.NET MVC: it's much, much, slower to develop in than Rails or Django.
Of course, none of this addresses the primary issues with ASP.NET MVC: it's much, much, slower to develop in than Rails or Django.
I'd say just the opposite. Things like deployment and things like gems are the big issues. Actually day to day dev work though, I think MVC is probably at least as productive as Rails or Django, if not moreso. But I think its personal taste more than anything else.
Code-generation has always been a major annoyance for real (ya, I said it) developers using MS tools. It'll be interesting to see if recipes are able to do what decades of similar promises from MS have failed to deliver.
I don't think Recipes are really meant to address codegen. It sounds like a simpler way to build Wizards, not much more than that. MS's solution to general codegen are things such as CCI (http://ccimetadata.codeplex.com/).
I disagree. MVC is quite good, but as both a Django and MVC developer I'm still more productive with Django. Certain niceties of MVC break down once your project falls outside of the mold of a cookie-cutter CRUD app interfacing with a 100% Microsoft ecosystem. People have levied a similar criticism against Django (once you color too far outside the lines, things get hard fast) but with MVC it can creep up on you much faster.
MVC shines if you treat it like a lightweight MVC framework and don't get caught up in doing things the "Microsoft" way -- this is massively counter-intuitive to anyone coming from a Python or Ruby background, who prefer to code in an idiomatic way by default. You can take advantage of its powerful routing system, various helper functions, and a decent templating language: Razor - which I hope Microsoft keeps and doesn't replace like it did to the 2 or 3 other templating syntax systems that proceeded it.
I find that Django doesn't even come close to MVC. But as to your second point, doing lightweight MVC (not the junk that MS has offered as examples) with Razor is by far the slickest, fastest development environment I've worked with for web.
Certain niceties of MVC break down once your project falls outside of the mold of a cookie-cutter CRUD app interfacing with a 100% Microsoft ecosystem.
I guess my question would be, what's an example of this. I find MVC with Razor extremely productive. I rarely even think of a framework when I'm using it -- I'm just typing what I'd like to make happen (for the most part).
And for me the tooling makes my life much easier. I know this is controversial statement for Django/Rails devs who are pretty much vi/emacs devs, but simple things like being to jump between quickly seeing all defs/uses/implementations of a method/property/class/assembly is extremely useful. But I hacked away on vi for almost 20 years, so I realize its allure.
> I guess my question would be, what's an example of this.
One example that stands out to me in the whole concept of strongly typed views. Nice in theory, but ultimately tightly coupling your view to your model (or your model to your view, depending on your perspective) is very Webforms-ish. You can tell they put in place these practices to ease adoption among the current crop of vanilla ASP.NET developers.
Another example is being able to quickly bake-in full-text-search into your application. With Python/Django you can use something like Haystack. Ruby has equivalents. With MVC, what are your options? Do it by hand with Lucene.NET? Get there a bit faster with .NET connector for Solr? This is more of a .NET ecosystem complaint, but ecosystems matter.
> And for me the tooling makes my life much easier.
I agree. Working with Visual Studio is great. With that said, I missed being able to "edit on the fly" my Python code and immediately pop into the browser to check, so now I just have a build script that builds and stages my projects automatically on an IIS server so I can accomplish what I got for free in Python/Django.
I think strongly typed views are an area where things fall down due to lack of guidance rather than design. I don't think a view model is the same thing as the model in MVC.
In my MVC apps, I use them pretty much exclusively, but they exist completely independently from my application model (they represent compositions thereof). This really only makes sense in apps of a certain scale, though, so having the option not to use them, or to use dynamic views (not sure if they count as strongly typed, but they are a weird middle ground) is definitely useful.
In reply to your first point, you should really consider using ViewModels. It a) makes views cleaner because it gives you a place to put formatting, and b) provides for some element of decoupling your views and models.
If you're passing models directly to views with Django, don't you have exactly the same problem?
What's wrong with strongly-typed views? I appreciate having the compiler do type checking for me so that I don't have to write a bunch of unnecessary unit tests to do the checks, and it makes refactoring straightforward. More importantly, on projects with larger teams, a strongly-typed view model means other developers can quickly understand expectations without having to dig into the view details, and designers can work on the view according to a fixed, documented and explicit contract independent of the progress of the implementation.
If you're working on a small, simple application with 2 or 3 other developers maybe it's not that big a deal, but on medium+ sized line of business application teams with 20+ developers it makes a massive difference when you need to fix somebody else's bug in an area you don't have much background in.
And what problems did you have building full-text search into your application? I used SQL Server + Full Text catalog for the first time ever recently and I was up and running in a few minutes. That being said I'm not familiar with what Lucene offers, so maybe you have something in mind that SQL Server does not support.
> I guess my question would be, what's an example of this.
I don't know if this is exactly what your parent had in mind, but I found it relatively difficult to make a REST API. I had to work around a lot of things with model binding and routing to come up with my solution, and even after that, I still find it kind of hacky. In addition to that, IIS fights you at several points along the way, for example by adding spurious HTTP headers or doing things like automatically redirecting certain status codes.
With a framework likes rails, this is baked right in. With the PHP framework I used to use, the framework was so transparent and lightweight that it was trivial to bend it to my whim.
A lot of this was exacerbated by the fact that it was much harder than it should be to set up my project to use the source code for the framework that it should be. In thoery, you just grab the project from MS, add it to your solution and change some references, but in practice, if you're using any other libraries that were built against the DLL from Microsoft, you run into issues, because the MS DLL is signed, and the DLL you build from source is not.
"and don't get caught up in doing things the "Microsoft" way"
agreed. I've been an ms dev for a while but over the last couple years have branched out into python.
Since then, I've really started to hate writing "best practice" code in .net where you get lost in a sea of interfaces and over-used design patterns.
T4 is used more for codegen; or, you can write a code-generator plugin for Visual Studio to handle a specific type of code generation (e.g., where you can expand a file in the solution/project pane and see the 'code-behind').
Most of the codegen for MS tools actually generates code in whatever language your project uses (like C#). CCI is a library for manipulating .NET bytecode, and is much lower-level than you'd normally need (or want) to deal with.
I don't think it's fair to say Microsoft never bought into jQuery.
They've continued moving toward jQuery-centric approaches on both the MVC and WebForms fronts, communicate to developers that it's the preferred approach for client-side development, devote development/testing resources to jQuery and jQuery UI, and threw out their MicrosoftAjax.js based validation for a new approach based entirely on jQuery and the jQuery Validation plugin (and I hear that's coming to WebForms as well).
Even the WCF team has reworked their client-side examples and libraries stuff to be based on jQuery and less cumbersome.
I believe what they're talking about regarding an "AJAX grid" is the idea of using an HTML helper to render a collection of data that matches up with what the upcoming jQuery UI Grid widget expects. You could still draw a parallel to server-controls there, but it seems harmless. Ultimately, it's the sort of thing we all end up writing ourselves anyway.
ASP.NET MVC is comparable to both Rails and Django in terms of speed, but you have to know what you're doing. Competency is required. But that shouldn't be a problem for a "real" developer such as yourself. ;)
God, I'm wrapping up a MVC3 app, I can't wait to sprint away and never, ever, ever come back. During this project I've, installed Visual Studio 3 times and my current installation leaves me still unable to debug Azure deployments and Microsoft has no fix for me but to reinstall Windows and start over.
.NET and csharp are a joy, but I'll never touch a pure-Microsoft stack or anything I can't (easily) run in Mono ever again.
What's the culprit do you think? Azure stuff? I've never seen problems like that with MVC3 (but given the gamut of all the crazy things I've seen I don't doubt you)
It's undoubtedly the Azure stuff. They had bad mirrors and redirects up for quite a while for VS SP1. Twitter revealed others with the same problem. That ruined the first install. The second install was okay with debugging a MVC project but the Azure emulator caused an uncaught exception in the .NET runtime. There was no indication of where the error was occurring, and like I said, no real troubleshooting steps available. I wish I could remember the error message. It was as if the runtime was just mocking me with it's complete lack of help.
31 comments
[ 4.5 ms ] story [ 108 ms ] threadThe feature that seems most likely to cause issues with a release would be Recipes because of their connection to NuGet. I'd expect to see a pretty feature complete CTP without that first, with the complete implementation being spread across one or two more.
I have no inside line on this, but I've been working with it since v1 so I follow it pretty closely.
I haven't seen anyone else really pushing Migrations that hard yet in the .NET space. Would be nice to see others trying to improve this space.
Orchard has this using NHibernate. Being unfamiliar with EF and NH though (long time LLBLGen user here) is this what you mean?
Yes, heaven forbid we .NET developers should rely on third party libraries...
The mention of a recipe for an AJAX grid is frightening though...like we are heading back into server-control world. Despite all the talk, MS never really bought into jQuery.
Also, I worry when the 2nd feature listed is that the default CSS/theme (which no one uses and is pretty ugly) supports mobile devices.
They mention deployment as a theme, but no feature to accompany it. It'll be interesting to see what they manage to do here. It's certainly a major pain point right now.
Of course, none of this addresses the primary issues with ASP.NET MVC: it's much, much, slower to develop in than Rails or Django.
I'd say just the opposite. Things like deployment and things like gems are the big issues. Actually day to day dev work though, I think MVC is probably at least as productive as Rails or Django, if not moreso. But I think its personal taste more than anything else.
Code-generation has always been a major annoyance for real (ya, I said it) developers using MS tools. It'll be interesting to see if recipes are able to do what decades of similar promises from MS have failed to deliver.
I don't think Recipes are really meant to address codegen. It sounds like a simpler way to build Wizards, not much more than that. MS's solution to general codegen are things such as CCI (http://ccimetadata.codeplex.com/).
MVC shines if you treat it like a lightweight MVC framework and don't get caught up in doing things the "Microsoft" way -- this is massively counter-intuitive to anyone coming from a Python or Ruby background, who prefer to code in an idiomatic way by default. You can take advantage of its powerful routing system, various helper functions, and a decent templating language: Razor - which I hope Microsoft keeps and doesn't replace like it did to the 2 or 3 other templating syntax systems that proceeded it.
I guess my question would be, what's an example of this. I find MVC with Razor extremely productive. I rarely even think of a framework when I'm using it -- I'm just typing what I'd like to make happen (for the most part).
And for me the tooling makes my life much easier. I know this is controversial statement for Django/Rails devs who are pretty much vi/emacs devs, but simple things like being to jump between quickly seeing all defs/uses/implementations of a method/property/class/assembly is extremely useful. But I hacked away on vi for almost 20 years, so I realize its allure.
One example that stands out to me in the whole concept of strongly typed views. Nice in theory, but ultimately tightly coupling your view to your model (or your model to your view, depending on your perspective) is very Webforms-ish. You can tell they put in place these practices to ease adoption among the current crop of vanilla ASP.NET developers.
Another example is being able to quickly bake-in full-text-search into your application. With Python/Django you can use something like Haystack. Ruby has equivalents. With MVC, what are your options? Do it by hand with Lucene.NET? Get there a bit faster with .NET connector for Solr? This is more of a .NET ecosystem complaint, but ecosystems matter.
> And for me the tooling makes my life much easier.
I agree. Working with Visual Studio is great. With that said, I missed being able to "edit on the fly" my Python code and immediately pop into the browser to check, so now I just have a build script that builds and stages my projects automatically on an IIS server so I can accomplish what I got for free in Python/Django.
In my MVC apps, I use them pretty much exclusively, but they exist completely independently from my application model (they represent compositions thereof). This really only makes sense in apps of a certain scale, though, so having the option not to use them, or to use dynamic views (not sure if they count as strongly typed, but they are a weird middle ground) is definitely useful.
If you're passing models directly to views with Django, don't you have exactly the same problem?
If you're working on a small, simple application with 2 or 3 other developers maybe it's not that big a deal, but on medium+ sized line of business application teams with 20+ developers it makes a massive difference when you need to fix somebody else's bug in an area you don't have much background in.
And what problems did you have building full-text search into your application? I used SQL Server + Full Text catalog for the first time ever recently and I was up and running in a few minutes. That being said I'm not familiar with what Lucene offers, so maybe you have something in mind that SQL Server does not support.
I don't know if this is exactly what your parent had in mind, but I found it relatively difficult to make a REST API. I had to work around a lot of things with model binding and routing to come up with my solution, and even after that, I still find it kind of hacky. In addition to that, IIS fights you at several points along the way, for example by adding spurious HTTP headers or doing things like automatically redirecting certain status codes.
With a framework likes rails, this is baked right in. With the PHP framework I used to use, the framework was so transparent and lightweight that it was trivial to bend it to my whim.
A lot of this was exacerbated by the fact that it was much harder than it should be to set up my project to use the source code for the framework that it should be. In thoery, you just grab the project from MS, add it to your solution and change some references, but in practice, if you're using any other libraries that were built against the DLL from Microsoft, you run into issues, because the MS DLL is signed, and the DLL you build from source is not.
agreed. I've been an ms dev for a while but over the last couple years have branched out into python. Since then, I've really started to hate writing "best practice" code in .net where you get lost in a sea of interfaces and over-used design patterns.
Most of the codegen for MS tools actually generates code in whatever language your project uses (like C#). CCI is a library for manipulating .NET bytecode, and is much lower-level than you'd normally need (or want) to deal with.
They've continued moving toward jQuery-centric approaches on both the MVC and WebForms fronts, communicate to developers that it's the preferred approach for client-side development, devote development/testing resources to jQuery and jQuery UI, and threw out their MicrosoftAjax.js based validation for a new approach based entirely on jQuery and the jQuery Validation plugin (and I hear that's coming to WebForms as well).
Even the WCF team has reworked their client-side examples and libraries stuff to be based on jQuery and less cumbersome.
I believe what they're talking about regarding an "AJAX grid" is the idea of using an HTML helper to render a collection of data that matches up with what the upcoming jQuery UI Grid widget expects. You could still draw a parallel to server-controls there, but it seems harmless. Ultimately, it's the sort of thing we all end up writing ourselves anyway.
.NET and csharp are a joy, but I'll never touch a pure-Microsoft stack or anything I can't (easily) run in Mono ever again.