.NET Framework 3.0: Indigo issues

The first two versions of Enterprise JavaBeans had a crucial problem: "enterprise" objects had a life-cycle different than that of "plain old Java objects." Types were loaded differently, instantiated differently, and the rules for them going away were different. The justification boils down to "things are different over the network," which is perfectly true, but ignores the problem that programmers balk at the requirement of juggling different life-cycles within the same solution.

WinFX / .NET Framework 3.0 is flirting with the same issue. Indigo/WCF, while having superior mechanics to EJB, also presents a different life-cycle for "enterprise" objects. As I said in "Should I Stay Or Should I Indigo?" last year, Microsoftian Don Box said WCF "extrud[es] a type system that we can think about independently of our CLR types," the visibility of the "service facade" is independent of the "in-memory facade," and WCF has attribute-based life-cycle control. By saying "it's the .NET Framework 3.0" I think MS is exactly repeating the EJB mistake. It is important that things that are different be packaged / named differently.

blogroll

social