﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Kevin Dente commented on On the faults of thinking: It is extensible, the users can add this</title><description>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.
</description><link>http://ayende.com/3049/on-the-faults-of-thinking-it-is-extensible-the-users-can-add-this#comment6</link><guid>http://ayende.com/3049/on-the-faults-of-thinking-it-is-extensible-the-users-can-add-this#comment6</guid><pubDate>Mon, 17 Dec 2007 18:29:18 GMT</pubDate></item><item><title>Adam Tybor commented on On the faults of thinking: It is extensible, the users can add this</title><description>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.
  
</description><link>http://ayende.com/3049/on-the-faults-of-thinking-it-is-extensible-the-users-can-add-this#comment5</link><guid>http://ayende.com/3049/on-the-faults-of-thinking-it-is-extensible-the-users-can-add-this#comment5</guid><pubDate>Mon, 17 Dec 2007 17:00:12 GMT</pubDate></item><item><title>Jimmy Bogard commented on On the faults of thinking: It is extensible, the users can add this</title><description>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.
</description><link>http://ayende.com/3049/on-the-faults-of-thinking-it-is-extensible-the-users-can-add-this#comment4</link><guid>http://ayende.com/3049/on-the-faults-of-thinking-it-is-extensible-the-users-can-add-this#comment4</guid><pubDate>Mon, 17 Dec 2007 14:37:20 GMT</pubDate></item><item><title>John Chapman commented on On the faults of thinking: It is extensible, the users can add this</title><description>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.
</description><link>http://ayende.com/3049/on-the-faults-of-thinking-it-is-extensible-the-users-can-add-this#comment3</link><guid>http://ayende.com/3049/on-the-faults-of-thinking-it-is-extensible-the-users-can-add-this#comment3</guid><pubDate>Mon, 17 Dec 2007 13:16:19 GMT</pubDate></item><item><title>Kyle Baley commented on On the faults of thinking: It is extensible, the users can add this</title><description>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.
</description><link>http://ayende.com/3049/on-the-faults-of-thinking-it-is-extensible-the-users-can-add-this#comment2</link><guid>http://ayende.com/3049/on-the-faults-of-thinking-it-is-extensible-the-users-can-add-this#comment2</guid><pubDate>Mon, 17 Dec 2007 12:50:27 GMT</pubDate></item><item><title>Haacked commented on On the faults of thinking: It is extensible, the users can add this</title><description>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?
</description><link>http://ayende.com/3049/on-the-faults-of-thinking-it-is-extensible-the-users-can-add-this#comment1</link><guid>http://ayende.com/3049/on-the-faults-of-thinking-it-is-extensible-the-users-can-add-this#comment1</guid><pubDate>Mon, 17 Dec 2007 08:58:45 GMT</pubDate></item></channel></rss>