I have just learned to appreciate DynamicResource after assuming I would never have to use it. This WPF declaration becomes necessary (for my work) when a centralizing Resource Dictionary, containing my ViewModel data sources, needs to be seen at design time (in Expression Blend) and run time. It follows that data contexts can be set like this:

DataContext={DynamicResource MyViewModelKey}

My previous technique was like this:

DataContext={Binding Source={StaticResource MyViewModelKey}}

Buy this book at Amazon.com! Comparing the two forms, gives me the chance to note that Binding.Source does not work with DynamicResource. The error messages thrown at me for this fact helped me to conclude incorrectly that DataContext cannot be set to DynamicResource. After a few experiments in Expression Blend it became clear to me that this is not the case.

Now the other stuff picked along the way, loosely related:

  • I’ve decided to use Laurent Bugnion’s IsInDesignMode property in ViewModelBase. This allows me to make ViewModel types with parameter-free constructors—and the use of the conventional d:DataContext, etc. for design-time stuff in Blend is needed less.
  • The attribute d:IsDataSource turns out to be very important in Blend. Without this attribute you can’t find ViewModel classes under the Data tab in Blend. I’m too tired right now to explain this more clearly.
  • StaticResource, DynamicResource, x:Static—what’s all this about?” by Tamir Khason tries to explain other stuff.
  • Here’s an MSDN reason why I held out against DynamicResource for so long: “A StaticResource must not attempt to make a forward reference to a resource that is defined lexically further within the XAML file. Attempting to do so is not supported, and even if such a reference does not fail, attempting the forward reference will incur a load time performance penalty when the internal hash tables representing a ResourceDictionary are searched. For best results, adjust the composition of your resource dictionaries such that forward references can be avoided. If you cannot avoid a forward reference, use DynamicResource Markup Extension instead.”
  • StackOverflow.com: “What’s the difference between StaticResource and DynamicResource in WPF?”—“A StaticResource will be resolved and assigned to the property during the loading of the XAML which occurs before the application is actually run. It will only be assigned once and any changes to resource dictionary ignored. A DynamicResource assigns an Expression object to the property during loading but does not actually lookup the resource until runtime when the Expression object is asked for the value. This defers looking up the resource until it is needed at runtime. A good example would be a forward reference to a resource defined later on in the XAML. Another example is a resource that will not even exist until runtime. It will update the target if the source resource dictionary is changed.”

I should know by now that MVVM is the theory that allows a developer to approach WPF with a decent plan. Sadly, the current release of Microsoft’s Entity Framework is full of great theories but the one that is most needed (for me and a few thousand others), Persistence Ignorance, is not supported. Here in the rasx() context, persistence ignorance, means that plain-old .NET objects can represent data from a database (a persistent store) while being completely ignorant of it. This is ideal for test coverage, loose coupling, simplicity and elegance.

I found out that Entity Framework was lacking so much elegance when I used it to back a WCF façade—while WCF met my meager expectations. My notes:

  • NHibernate does not have Persistence Ignorance problems. But avoid XML configuration hell with Fluent NHibernate—an idea started by C# MVP and StuctureMap architect, Jeremy Miller.
  • This post, “Persistence Ignorance in the Entity Framework,” in the Data Platform Development Forums represents a great historical moment (from two years ago) when the developers complain directly to attentive folks at Microsoft.
  • ADO.NET team blog : Sneak Preview: Persistence Ignorance and POCO in Entity Framework 4.0”—the title speaks for itself…
  • Aleem Bawany: “The Entity Object violates the Single Responsibility Principle because other than representing a Person it takes on the additional responsibility of managing data persistence.”
  • Persistence Ignorance (POCO) Adapter for Entity Framework is available for the current release of Entities Framework. This project came to me from stackoverflow.com.
  • Frans Bouma, via Paul Gielens (rightfully) defends the technical achievements in Java when confined to this specific issue: “Be aware that the .NET world isn’t comparable with the java world. In the java world, there are standards like EJB-CMP, so having POJO objects is key. In .NET it’s not, you need non-POCO objects to get decent databinding, remoting and xml serialization (cyclic references, interface types etc.)…” This defends comes to us from year 2005…
  • I got a System.ServiceModel.CommunicationException, “The underlying connection was closed: The connection was closed unexpectedly.” It appeared to be related to attempting to emit a composite object without [DataContract] attributes.
  • I found hard, clear limitations in LINQ to Entities. A guy named Moses who really lives in Egypt, Muhammad Mosa, found the same limitation over a year ago: “By design, LINQ to Entities requires the whole LINQ query expression to be translated to a server query. Only a few uncorrelated subexpressions (expressions in the query that do not depend on the results from the server) are evaluated on the client before the query is translated. Arbitrary method invocations that do not have a known translation, like GetProducts() in this case, are not supported…”
  • While writing LINQ queries, I was tempted for a few seconds to attempt to implicitly cast an anonymous object to an interface. Did not work out because anonymous types “…cannot be cast to any type except for object.”

It turns out that my previous use of the concepts I call output definitions, input definitions and data transfer contracts apply to this WCF solution. I tend to think that my .NET 2.0 approaches are either obsolete or auto-magical in the .NET 3.5 world. Not all the time…

Relics of My Failed Yahoo! Interview Besides my deteriorating “presentation skills” during job interviews, my long-term (and respectable) problems are in lacking “high traffic” and e-commerce experience. It just recently occurred to me to search stackoverflow.com for these issues. I am somewhat relieved because what I found there was not too unexpected—but there was one surprise.

In “How does one get experience developing high volume websites?,” Nic Wise answers, “Join a big company which has one or more of them. Eg I’m working at the BBC, which is a fairly large site :)” Not bloody surprising. In my Southern California market, after about 12 years, I am unable to meet with any company here with a high-traffic, public-facing presence—except for Yahoo! Santa Monica (my first, 2009 interview). I’ve done high-traffic stuff behind the firewall but that’s not “good” enough—clearly I’m not working for Yahoo! in Santa Monica.

In “What does eCommerce programming involve?,” I was bizarrely relieved for the lack of answers. Too many answers would have meant that I’m just outclassed and my information is outdated. Stackoverflow.com user, “unkwntech,” responds with “eCommerce has one big word that goes with it Security” and a few important technical details that I will certainly look into later… A related question, “How to test eCommerce software for credit cards?,” does remind me of the importance of Paypal.com and its ecommerce sandbox. Based on my knowledge (which is limited), without Paypal.com (or Google checkout), we would have to secure merchant bank accounts to play most ecommerce war games. The last time I checked into merchant accounts, a figure of US$10,000 popped up and spooked me.

5 years experience == 100k+ salary? Really?” is a very popular question in this particular genre. This question need not be answered by me but I liked many of the responses. Gabriel Isenberg tells an old, sad truth: “Switching positions nets a far higher merit increase than sticking at the same place. Measuring average merit increase at the same place for 5 years isn’t going to get you real-world information, I don’t think.” DarenW sounds almost like me: “Hah! With 20 years experience in software development, I’m still making relatively piddly for the industry. My personal pitfalls were: working tiny start-ups with minimal cash flow or capital, working for non-profits, working in the academic world, and returning to grad school at one point.”

Another very important question to me is, “Old Developers—any future?” Very inspiring… and surprising!