+972 52-548-6969
On the faults of thinking: It is extensible, the users can add this
Two posts and a discussion yesterday has finally made it clear what my stance in regards to extensibility is. Extensibility is well and good, but if I need to extend a product from the get-go, just to get the basic functionality going, then this product blew it.
The discussion that I had was about SSIS and the need to create a DateParserComponent. Basically, a wrapper around DateTime.ParseExact(). I don't mind the work in creating it, but it is very telling that this is something that you would need. The posts that help cement this thinking were Phil Haack about Convection Controller and Ivan's Filters implementation for the MS MVC framework.
Let us start by saying that neither posts has code that I can take to production, and that is explicitly state in the posts. Demo code is demo code, after all.
Nevertheless, I am going to talk about this demo code, and its implications. Phil has posted this Convention Controller as a way to show how easy it is to extend the MS MVC framework. The problem with that this is showing how to extend the MS MVC framework for demos. The code required to make this run for production is far more complex*.
Production code has to be reliable, performant, stable, etc. A lot of effort goes into taking a piece of code from the proof of concept stage to the ready to production stage.
I believe that extensibility is extremely important. But that to answer of "you can extend the product" for any core scenario is nothing but blame shifting. I mean, Date Parsing in an ETL tool? Can you really consider that as a noncore scenario?
Now, in order to avoid the hordes of people that this will offend. I want to make one thing clear, convention controller is not a core scenario for the MS MVC framework. That is a by design choice of them that I disagree with, but that is the way it is.
We now begin to see a lot of the MonoRail stuff appearing on the MS MVC side, Rescues, Filters, etc. I hope that most of them would end up with the core product, but MS has stated the MonoRail feature parity is not a goal.
Just keep this in mind the next time that you are going to say "it is extensible, do this", you really ought to consider whatever this is an answer that is driven by the product's core scenarios vs. moving the work that should be yours to someone else's hands.
* This post is not about the convention controller, but to foretell the usual nitpickers, reflection is slow. Using un-cached reflection in a hotspot is a bad idea, even cached reflection is inappropriate at times.
Comments
Well to be fair, the ConventionController isn't an example of extensibility to enable a scenario. There isn't any scenario blocked by not having ControllerConvention.
It's really an example of extensibility to enable a pattern of development style that is a matter of taste. Some people prefer not having to label actions with ControllerAction.
What would be worse is if you had to extend our class in order to handle core scenarios. In other words, without extending the framework. you simply can't get foo done, whatever foo may be. In that case, we'd need to look hard at why we require extensibility to get the job done.
Now for edge cases that are not core scenarios, it seems extensibility is the right solution. After all, why have extensibility unless there are scenarios you are not going to support out of the box?
While I agree with the sentiment, it seems a little early to be calling Microsoft out for not including certain "core" features in MVC. You assume filters won't be included from the statement that they won't be including all features from MonoRail.
If I were to be optimistic, I'd argue that they released a more stripped-down version early to solicit feedback on what's missing.
I agree with Kyle. It is way to early to be criticizing the MVC framework for the points you have listed. It is not yet clear what the full functionality of this framework will be going forward.
The ConventionController is just showing that if you try to follow a different convention than what Microsoft uses by default (I actually like their [ControllerAction] attribute, go figure), you have the ability to change it if you want to.
I think a key advantage with the extensibility for the MVC framework is that it is so early in the process. If someone in the community extends the framework in a really cool way, I think that will help Microsoft shape the product or at least provide the best options for people by the time the framework is released.
Also keep in mind that this framework is targeted at a huge market segment. As good as MonoRail is, it is highly unlikely that it could ever achieve the market penetration that this framework will achieve. I know that is just because it is Microsoft. But that also means they have more complaining developers to deal with. Honestly, I think we're almost impossible to keep happy. No matter what one segment will be in outrage over whatever decisions they make. So at least that segment will have the ability to extend and modify as they see fit now.
Lets see how this one plays out.
I think the point was not to criticize ASP.NET MVC, but to highlight the apparent choice between offering extensibility vs. hitting core scenarios. If you don't hit core scenarios through your own extensibility model, how could you possibly know if your extensibility points are worth anything?
This is similar to shipping an API with that defines interface but no implementations. How do you know your interface is correct if you don't ship at least one core scenario through an implementation? You don't, really.
In SSIS, it seemed like a lot of "extensibility points" (I use the term loosely) were created with only very trivial implementations shipped (i.e., the Connection Managers). Any real-world implementation took far more effort than just ETL'ing it by hand through a custom app. If your source schema doesn't match your destination schema, well, good luck.
Extensibility points are great, but unless they're proven with core scenarios, there's a good chance they won't meet real-world needs.
Couldn't agree more Ayende... I know its CTP, but I am just not entirely sure about some of the design decisions and what the framework will look like as more features get added.
I do not doubt that features will come, but now I wonder at what expense. Once a CTP is released the API and "conventions" are pretty much set in stone. I look at some responses in the forum and on blogs, and some problems appear to be being solved by throwing overloads in, proposing testing with internal classes, very heavy controllers, poor url and route resolution, etc.
I think when you need internal classes to test, something is wrong with your api. TDD usually helps a lot to fix this, test coverage is great, but backfilling tests isn't what TDD is about.
When you throw method overloads at the problem your trying to capture every use case with an overload which is not possible, not solve the real problem.
While its still early, the MVC Contrib project is going to look a lot like Monorail on MS MVC.
Actually, it's NOT too early to be calling out Microsoft on issues with ASP.NET MVC. In fact, I'm far more worried that it's too late for feedback than it's too early. MS has a history of releasing bits and then telling us its too late in the development cycle to incorporate feedback. This has happened too many times for me to be optimistic.
Comment preview