Yesterday, I got to go to the MSDN Unleashed event at the Microsoft office in Southfield, MI. It was a pretty small event. The topics were WPF, and .net 3.5 sp1 additions. The demos for WPF were pretty good. The whole time I watched the demos, I had two thoughts:
1. Jeez, this seems like a lot of work to change the way I do UIs so they can be WPF UIs. Some of this seems a little clunky. What is the benefit? All my projects only run on desktops or the web. There didn’t seem to be any compelling reason to slow down my work by switching to WPF. Or am I just being a curmudgeon? Maybe I should bite the bullet and just switch because it is the new stuff. Which brings me to my second thought.
2. Is this going to stick around? If I make a big personal investment into becoming proficient with WPF, will it benefit me and will WPF stick around? If I switch over to WPF and it dies or MS abandons it, I will be screwed because all the programs I did in WPF will be unmaintainable and I will be blamed. It is kinda risky. So, again, back to “what is the reward”?
So far, I haven’t found an answer to this. Some day, if anyone ever reads my crappy blog and has an opinion on the matter, let me know.
With the presentation on the Entity Framework. I liked the way that Bill Steele whipped up a EF model, then tossed it into a program and bound to the data quickly. That was totally cool. However, I think he glossed over one of the biggest selling points of EF. When I prepared for my presentation for Lansing Day of Dotnet, I felt that I needed to answer the question: “what does EF give me over the table-to-object tool that comes with LINQ”. There were two things that stood out to me.
1. I really like the way that an EF model allows you to bind to Stored procedures to do your insert/update/delete calls. That is slick. I know the LINQ tool allows you to do that too, but I like the EF way better.
2. I love the way that EF crawls foreign keys and builds/embeds related objects (wrappers for related tables) as properties of a table. For example, a customer, has orders, an order has products. So, EF creates a customer object with a property “Orders” that contains an array of objects holding ONLY the related orders for each customer. The Orders object is not populated until you ask it to be populated. That is sooooo cool! I look back at several of the object models and data layers that I have worked with over the years, and I wish they all had worked the way EF does. Plus, EF does all of it automatically. That is dead-sexy. I can’t believe anyone would do a demo of EF and not talk about that. Maybe he figured everyone already knew about it.
The last segment was about scaffolding and data services. All those were done using declarative programming. Let me say this: I don’t like declarative programming for 2 reasons:
1. When declarative programming works, its nice, but when it doesn’t work, you have no way to debug, it. Its maddening and I hate it. I’d rather do imperative programming and be in control and be able to step through the code and find the error.
2. Declarative programming is for script kiddies. Real programmers program. They don’t drag & drop or change properties and call that a program. At some point, a declarative programmer will reach the limits of their tool and find they be forced to do some detour programming (circumventing their tool) and that is very painful. It is worst when they come to you or me for help, because there is no solution/fix and it just grates my nerves to say “can’t” to any programming or debugging request. I’m sure it grates their nerves too.
So, when I looked at scaffolding and data services, it only seemed like a very cool idea. It also seems like a quagmire that I would like to avoid.
Also, during the data services demo, I had to chuckle to myself when someone in the audience asked about security for the data web services stuff. The presenter showed how you could set each table in the database to be readable, writeable and/or deleteable. Great. He didn’t say what to do if you want a customer to read their own Purchase Order history but prevent them from seeing other people’s histories. Um, that kind of security is, um, everything to me. There were no hints how to do that.
Overall, I would say the MSDN event was totally worth attending! Even when I go there and see technologies that are not a good fit where I work, it is nice to see them and understand them. Then, if someone comes to me and says, “Hey, I think we should be using this new thing”. I can tell them why they are right or wrong. If I hadn’t been to the MSDN event, I would have to give them the benefit of the doubt and trust that they listened with the same discerning ear that I would.