I love the way MVC separates out the code that used to get thrown into the same code behind in web forms. It really shines in that regard. Who knows maybe it will have a positive influence on webforms apps in that regard.

For the moment my bottom line is that it takes a lot longer to write the same functionality in MVC than webforms. That’s partly due to the learning curve and partly due to the fact that there is more code to write. The fact that there is more code will be interesting to watch. Maybe in time people will find some efficient practices that will help to bring down the overall effort required. If thats not the case I wonder how someone would justify the cost of building a system one way versus another. And dont tell me to build it in MVC because webforms are evil. Thats nonesense. We have almost ten years of webform driven sites out there.

Lastly, for all those folks who are jumping on the “Viewstate is evil” bandwagon – which seems to be the same lemmings who jumped on Datasets as a DAO in 2002 – have a look at the following performance test. 6-8 requests per second for an MVC app is laughable. I sure hope that’s not the case presently. Its worth some internal testing to see. By the way, just on a purely subjective note, for the past year I have frequently spent time on MarketWatch. Since they switched to MVC I have noticed a small performance penalty. Purely subjective. Heck maybe its even a matter of browsers.

Fast forward to 2009. ASP.NET MVC hits the market. Only its not just routing and actions its a whole big kit and kaboodle. Reminds me a little of RoR. Along the way all of a sudden a lot of folks are complaining that Viewstate is the big evil and if only they could code without it. Meh. Sounds a little like people flocking to the latest shiniest thing. And there is nothing wrong with that. Its just ironic that many of the personality types that flock to this technology are the same type of folks who argued that datasets would save the world. Geez.

MVC is good stuff and my buddy Phil has poured his heart into this project. So I certainly hope it will thrive and progress. What has me confused at the moment are a plethora of adjacent projects that are growing up around it. I have a hard time discerning which to take serious. What do I make of an open source “architecture” that spits out a bunch of scaffolding pages and uses itself two other OSS projects. By the way, am I the only one who sees a trend of OSS projects where someone produces an entire new something that is 50% built on top of someone elses new something. Hope that makes sense. Did the RoR community go through a similar evolution?

As a consultant I need rock solid tools that are not necessarily going to be impacted by a deprecation of some obscure aspect because the manufacturer used some OSS project that is no longer popular. I really should research how the RoR community deals with this.

And while I am on the subject of “architectures”…. seems that there are some ASP.NET MVC “architectures” floating around that are primarily fantastic code generators. I would actually call them Form Wizards on Steroids. Hence the pic.

In 1992 I worked on a pretty large MS Access app. Yes we did those and they were good. Dont laugh. MS Access was the MVC of its day. Anyways, the IDE had a Form Wizard. Point it at a query or table and it would generate all the code you need. I learned an important lesson back then about code gen. Especially UI code gen. Dont use it. Wizard generated code is great … al the way until you need to change it. And Wizard generated apps tend to contain a lot of unnecessary stuff that you wouldn’t produce by hand.

Now mind you I am not talking about the utilization of some other view engine. Spark for example looks pretty cool. I am talking about the notion that a utility spitting out a bunch of views and controllers and tests is a measure of productivity. It is not.

Speaking of productivity. Rob Connery had a very cool demo of MSpec on his site. Finally a spec / test system that makes sense. (Besides Fitnesse that is).

Speaking of interesting, Rick Strahl came across yet another one of those WTF scenarios with LINQ. Apparently it manages to create circular references when you try to serialize objects. That’s so lame its unbelievable. What I do not understand in all these issues that LINQ seems to have (and unless I am mistaken that the Entity Framework also has here and there) – what I really don’t understand is the fact that ORM has been around for ages. Entity Relations were first defined in the 70’s by Dr. Peter Chen. How is it that the Architecture Astronauts at MS can’t get their act together and produce this stuff without numbskull problems like this.  I have long since given up on completely problem free releases, but some of the recent technologies that are being evangelized seem to have a higher than normal quotient of WTF errors.  Is it any wonder there are a number of dissatisfied voices out there.

Luckily in the case of ORM tools there are a number of viable commercial and Open Source alternatives available.

UPDATE: And if you really want something to make your eyes roll back in your head, check out Roger Jennings list. I especially took notice of the part where Roger mentioned that his concerns were pretty much ignored on the forum. Now folks, Roger goes way way back in the database world. If MS simply ignores the comments of a thorough and conscientious developer like him… imagine what else gets skipped, ignored, shuffled under the carpet and overpowered by marketing and evangelism. I continue to say it again and again this project has a distinct smell. And yes I DO have my own agenda here.

Have you ever gotten into a situation where your customers development team uses tools that you know full well are not best of breed, but you go along with it and use them for their project because…. well they are the customer and pay the bills. I have precisely such a case. The customers dev team requested that we use MS Enterprise Blocks for logging and exception handling. Primarily because thats what they have standardized on, and its easier for them to maintain this code if it contains the MS blocks.

Now normally we use Log4Net. Want to know why?

For starters its open source. And secondly its better built and faster.  Here is actually some empirical evidence how much faster it is. In this test it took Log4Net about 40ms to log 1000 messages while the Enterprise Library took a whopping 9500ms. That’s pretty incredible isn’t it.

There is an old saying. Don’t know where it comes from, but it goes something like this : ” Whose bread you eat – whose song you sing”. Meaning the customer is paying for it and if they like this tool we will implement it. Even if it is a bit of a pig and slow.

Of course there is plenty of discussion of the code and design quality presented by the EntLib.  Oren Eini set off a huge discussion in March 2007 when he called the Patterns and Practices group on the carpet. In spirit and meaning that wasn’t all too different from this post by PluralSight all the way back in 2003.

Face it, its very hard to turn a sows ear into a purse.

You know, I haven’t used any of their stuff since the original DAAB back in 2003 or thereabouts. Once I started to work with ORM’s and once there were some valid .NET OSS projects out there I never looked back.

Just for reference ( since I will need it in the near future ) here are a couple articles on configuring MS Blocks for Logging.

http://www.devx.com/dotnet/Article/31463
http://www.cubido.at/Blog/tabid/176/EntryID/33/Default.aspx

Does anyone remember all the crazy overloaded methods in the first lib to come out of MS – the DAL.

Read more

Watch the show here

Read more.

Dare added together the some of his experiences. You would be surprised how many projects I’ve seen like this. I especially like the piece on Schedule Chicken. Its fantastic.

I think this list is almost as great as Spolsky’s top 10 check list for tools and process.

Link here…..