Well I have a night, a breakfast, and a flight standing between me and PDC 08. I’ve been totally excited about going since I
conned convinced the job to send me (back in August I think). This is my first development related conference. There’s going to be a LOT of stuff to see, learn about, and interact with…and that’s not including the actual conference sessions.
A number of the WPF Disciples will be at the PDC (this will be the first time I’ve met many of them in person…save one). And we’ve planned some social events as well as shop talk events (although it might be difficult to distinguish the two).
I’ve entered Flow into the PDC Show Off contest…so if you’re at PDC, please be sure to come support me. Even if I don’t win, it will still be a great event to see what other people out there are doing with Technology.
I will live blog from the Keynotes and the sessions I attend. I will also provide a daily recap. In addition you can follow my Tweets (can’t believe I was the first to get that name), where I’ll inevitably be posting a quick OMFG reaction to things I learn. If you’re going to the Conference, look for me…I’ll have a (limited) supply of Brownie Point Badges to hand out…they will most likely come in useful at a later point in time.
You need to view this with silverlight and is best viewed full screen.
Microsoft unveiled VS 2010 (codenamed “Rosario”) recently. Soma has started a series of posts looking at the new features in depth. What I really love in this announcement is that starting now Team Edition for Developers and Team Edition for DB Pros are joined at the hip. Hopefully this means that some of the DB Pro functionality will filter down to the Professional edition similar to the unit testing functionality that’s there now.
There are many more exciting features in 2010, like real UML support, more focus on the non-developer stakeholders in an application, and a ton of other stuff. I really can’t be much more than an echo box at this point, so I just suggest going to the VS 2010 Overview and seeing for yourself.
I don’t want to appear ungrateful to colleagues who help me out. Therefore, I think that I owe a long overdue thank you to Christian Graus for giving me an MSDN Team Suite subscription back in 2006, and to Joseph Cooney for giving me one this year. Oddly enough, both of my benefactors are Aussies. Both gave me the subscriptions through the MVP program. Maybe one day I’ll do something to merit being an MVP and won’t have to bum subscriptions from other people 😉
I had the opportunity to work with Christian on an interesting project called DIA, a digital veterinary encyclopedia. The front-end was powered by WPF and had some very interesting features.
Joseph and I chat more frequently than should be possible because of my strange sleeping (or non-sleeping) habits. He is a WPF/Client App Dev MVP, and he provided a lot of support and guidance as I was learning WPF. There are a ton of other people I could thank. Practically everyone in the WPF Disciples has either helped me learn WPF or helped me solidify one of my crazy concepts. My wife for being supportive of my obsession with technology over these past 6 years. And everyone else who has helped me as I have grown as a software engineer.
Ayende (he gets upset when I refer to him as Oren) recently posted on his blog an opinion that I doubt many of my readers will disagree with. Someone bemoaned that businesses perpetuate the current state of the software development industry where “just getting things done” is more important than doing it right. My thoughts are below.
This is a problem that will continue to persist as long as businesses can get "functional" code that works good enough to solve their problems.
It is very difficult to convince a businessperson that Potential value justifies extra up front costs. Even more difficult is convincing them that future savings in maintenance (which may or may not happen in their eyes) is worth the extra money it takes to hire a developer that can inject that maintainability into their application…or the extra time it takes to do that instead of "Just getting it done".
A faulty bridge is a very tangible concept, if I drive over a poorly constructed bridge it could collapse and I’ll fall 200 feet into the river below. Code that needs to be rewritten will not necessarily cause the company to collapse. When deciding where to place their budget dollars, a company will choose 9 times out of 10 to pocket the savings and incur the technical debt later over paying the costs now and realizing the savings later.
This is the same thing that causes people to swipe their credit card for an item they can’t afford and pay three to four times the cost in interest later.
There has been something nagging me tremendously about the Entity Framework Vote of No Confidence. I haven’t had the time up to now to put my thoughts together regarding this. Now that I’ve got a little more breathing room, I think it’s time that I address the elephant in the living room.
Here is what Roger Jennings argue are the major pain points as reported by Mary-Jo Foley:
1. Domain-driven design (objects-first) is today’s hot design pattern for enterprise apps and requires starting with optimal design of business objects and relationships, not from the schema of a relational database whose only job is to persist (store) the objects. Microsoft has always had a data-centric (data-first), forms-over-data approach to pseudo business objects. Data-first can lead to suboptimal business object design.
2. Persistence ignorance requires Plain Old CLR Object (POCO) because it enables separation of concerns, which is de rigeur in today’s layered/tiered software designs. (Persistence ignorance won’t be part of the Entity Framework until Version 2, Jennings noted.)
3. Test-driven design (TDD). MSFT came late to the TDD and Agile Programming table and is trying to catch up. However, no one on the Entity Framework team worried about testability during the design phase. The problem is that performance of unit tests with business objects connected to databases is terrible.
Let’s talk about these in order:
- Looking past obvious argument that “today’s hot design pattern” is tomorrow’s “what were they thinking” (anyone still trying to use CORBA as core of their distributed architecture), Microsoft’s strategy has always been to make getting a “working” solution as painless as possible. Besides calling DDD “today’s hot design pattern” is akin to calling the computer “today’s hot information storage medium.” It severely demeans the timelessness of the core concepts of DDD.
I know that for some (me included), considerations like maintainability, flexibility, and scalability are a concern when designing and developing applications. However, for better or worse, there are some people who just want functional software (the scary reality is that the latter group outnumbers the former by a LOT). This is the reality of the market we live in and if Microsoft did not target those developers, there will undoubtedly be another vendor who is more than happy to cater to what some argue is 98% of the development market. This isn’t going away until the software industry is regulated.
- What about Entity Framework precludes Persistence Ignorance? Are you actually proposing that your database entity model and your Domain Model should be one and the same? To me no matter what O/RM solution you are using, you are leaking too much of your storage implementation into your Domain if your entity model and domain model are one and the same. At the other end of the spectrum (the UI Layer), many agree that your domain model and your presentation model in complex scenarios should not be the same, because presentation is a different domain than your business domain. In the same regard persistence is a separate domain from your business domain.
- If you agree with me on point 2 then point 3 is moot. Your business objects are not tied to your entity objects. So you are free to test them with out being connected to the database.
What I’m saying here is that you should think of your data layer as a separate domain in and of itself from your business layer. Once you make that leap, you’ll see that the arguments against Entity Framework are unfounded because it presumes that your business layer and entity layer are one in the same.
If that argument is not compelling enough for you, ask yourself this one simple question: which would you prefer to maintain, an application built using datasets to the form, on one built with EF objects to the form?
David Hill recently announced the first drop of Prism 2.0. As he mentions, the primary goal of this release is to better enable a UI agnostic approach to developing an app that can target both Silverlight and WPF. Funny thing is that the sample app is WPF-based MLS client…hmmm where have I heard that before? I guess the time has come for me to finally dive into SL development.