patrick.net

Why the fuss over the latest and greatest patterns?
I'm in the Job market the contract I've been working for the last 4 years, has ended for now. So I placed my resume out there, and all of the calls are explicitly asking for 3 or more years developing in nothing but MVC, IoC, using and Dependency Injection.
I usually get to chose the technology I use on projects. MVC is nice and has it's uses, but developing your whole domain structure using MVC applications is not something I would normally do. Entity Framework is slick to, but if you like wizard driven development, then why not just use Data controls and DataViews for every thing, and make the data calls directly from the aspx pages? At the end of the day, that's what you're doing. What's the difference in having this extra layer that interprits SQL style syntax and directly selects, inserts, or updates tables from the data base. With three of or four layers between, or just directly accessing the database from the web page?

We abandoned ASP and the Alligator tags, but now the VIEW part of the MCV pattern brings them back to deal with. MVC seems to a hodgepodge of everything wrong, Microsoft told us to abandon back in 1999, when the ASP.NET beta came out.

See I came from a VB6 back ground, and as soon as .NET came out, the biggest thing Microsoft drilled was NTeir Architecture. BLL, DAL and your presentation DLLs.
Then Generic Objects came out, and things really got standardized and simple.

All the fuss to learn Nteir architecture, and type safe objects, to just have Microsoft turn it upside down to appease the "That's not how we do it on Unix" crowd.
Then along comes LINQ, very good concept, I love it for querying Domain objects I've loaded. Gone are the days of me writing out enumerations sequences to get to the object I need to use. The most advanced usage I've seen LINQ used, would have been major TABOO in the .NET world in early 2000.

I once did some work on a Car dealership management software webapp. He had this Indian guy, build the whole thing around the Entity Framework. It worked and got the job accomplished. But with the Entity Model acting as a surrogate database, I found my self asking myself over and over, "Well why not just create a SQL command in line of the webforms, and build queries that accesses the data directly from the database? What's the difference if you're using the Entity framework and using linq instead of a SQLadapter?

At the end of the day Entity frameworks, are using reflection to match the data fields to objects that look just like the business objects I write anyway. So why the extra layer. LINQ creates a List and has to rely on enumeration to perform the SQL like queries. Then you end up with a list anyway, you may still need to enumerate to finish your task.

I love LINQ don't get me wrong, but I'm still a firm believer in building a strong business model, and a DAL that calls on Sprocs that can be managed in the DB. Or customized to use any data provider.

LINQ to comes in real handy for working with Objects and nested Lists, whittling down a collection to unique keys for combo boxes, is an excellent example. Sorting and Filters for reports, with out having to recall the DB.
Any time you ever wished as a Programmer I wish I could query my objects like we do in SQL. Is an excellent reason for LINQ. I certainly wouldn't want to use it for accessing all of my data, and basically have all of my database calls wrapped up in compiled code.

Now back to MVC, if you follow the design principals, that Microsoft still uses under the hood of the other technology. Like Generics, Reflection, and Domain objects. This all seems to be a layer of abstraction for those that either don't know any better, or are lazy. Then when you go back and try to implement things like MVC for anything other than CRM, it becomes a cumbersome mess.

And if you write your interfaces for your classes, then things like Castle dependency injection becomes a moot point as well.

More over if I were hiring, I would want an old school programmer, that can program in any language you throw at him, using any library or pattern.
Those that are well versed in just one thing and have only used it for the last 3 years, what good will they be. When Microsoft changes the game next service patch or Visual Studio release, with even newer and slicker technology?

I think the idea is to know them, learn them, love them, but only use them where necessary.