Rants
Tim Heuer again to the rescue. I had started a Dynamic .xap file demo to figure out how all that dynamic .xap stuff worked when he released a new video detailing it exceptionally. Run over to Method ~ of ~ failed and see the other videos he has for you...
I've been digging into some of the open source and 3rd party controls that are becoming available for Silverlight 2. While running into some odd issues with some of them it occurred to me that there are some design guidelines that haven't been well communicated. Back in the early days of WPF I learned (though exactly where is unclear) that every control should support an empty constructor and that all properties (e.g. XAML Attributes) should have a default value. I knew this to be true but I couldn't document where it came from.
So as usual when I am stuck, I contacted Chris Sells as he was my mentor in early XAML usage. He was at MSDN at the time gathering content and helped me get the Data Binding articles as well into the Software Design Review for WPF (then Avalon). If anyone could help me figure out where I learned this, he'd know. He reminded me of the language they use internally: "Create-Set-Use". Essentially this means that the design pattern for controls is that they should work without requiring any properties:
<Grid ...>
<Rectangle />
</Grid>
You can see that the Rectangle doesn't require any properties to be valid. Of course this Rectangle has no fill brush and no stroke brush which means it will likely not be visible. But that's OK because it is valid XAML and doesn't break. The XAML for a control doesn't have to read the mind of the user, but should behave (e.g. not throw exceptions). One of the most egregious was a control that threw an exception if I failed to set the Width and Height. Worse yet, when it did throw these exceptions, it didn't tell me what *all* the properties I needed therefore it was painful to use. Width and Height are particularly problematic in this way in that by not defaulting to "Auto", showing the control in a non-Canvas container meant I needed to set "Auto" to the values which is what they should *always* be defaulted to.
Create-Set-Use happens during parsing of the XAML. This comes back to thinking of XAML as a serialization format for in-memory objects. XAML is simply a way to define what the structure of a particular document should be when its de-serialized. If you keep in mind that an Element becomes an object construction and that properties become SetValue calls, it makes it fairly clear what is happening during the parsing of the XAML itself.
As you write your own Silverlight or WPF classes that you expect to be used in XAML (this includes controls but also may be types that can be created as resources), try to keep these design ideas in mind. It will make life easier for your users.
The Entity Framework "No Confidence Vote" is a couple of days old now. I wanted to give the Internet a couple of days to chew it over and figure out where it really fit into the big picture. If you follow me on Twitter you may have seen some back and forth between Scott Belware and I recently. Most of this back and forth has been about his attacks of the Microsoft community (attacks of the technology or even the company are fair game as far as I am concerned). Getting personal by accusing me, the Microsoft community or even individual EF Team member's directly seems petty and unnecessary.
In that same light, some of the ALT.NET community (I won't name names) have accused me of being a shill for Microsoft's techologies. Anyone who has ever seen me talk about any Microsoft technology already knows that I pride myself in my centrist view of any technology (Microsoft's or others).
For me the power of the Entity Framework is *not* in its use as a ORM. There are dozens if not hundreds of ORMs out there. Depending on your specific use case, some are great...some are less than great. None is a perfect ORM for every case. My attitude about the Entity Framework is that it isn't a great ORM...but that it isn't trying to be. The power of the Entity Framework is in a common language for communicating a model. The Entity Data Model can handle complex scenarios. The big advantage in using the Entity Framework comes when the Entity Data Model is used by Microsoft and external projects. The effort required in building a real model of existing enterprise data is not trivial. The labor involved can only be recouped if the model is useful in other scenarios as a model of your data throughout your organization. That's not the case yet. Microsoft isn't there. In addition, the Entity Framework is not a good tool for the top-down development that Domain Driven Design and Model Driven Design are espousing. Again, I don't think that was ever their intention. But its important to know. There are other criticisms of the technology to me made but that's not the purpose of this post. Instead its to say that its a great start on a long-term strategy and for many people now isn't yet the time to use the Entity Framework.
But that being said, what is my opinion the No Confidence Vote? I don't think the technology should be killed. I think its a great start but still flawed as many v1 technologies are. My chief complaint with the whole movement in trying to kill the Entity Framework is the tone of the message. Angry bitter attacks on Microsoft and the Microsoft community do not help create dialog. It just creates division and a dug-in mentality. My experience is that if you attack a side, they are unlikely to change their minds but instead will just becoming more resistence to listening. Maybe that's the point. If you create an environment where Microsoft fails, then maybe nHibernate will get more traction.
So what do I think of nHibernate specifically (as it is the elephant in the living room that no one wants to mention)? Its a great framework. Period. I use it and have used and recommended it with past clients. I will continue to recommend it (and actually recommended it as well as other ORM's in a recent user group talk in defference to the Entity Framework in the v1 timeframe). So why do I care about the Entity Framework if I like nHibernate? Because they meet different goals. nHibernate is a persistence framework (or a ORM if you prefer). But it doesn't attempt or do a very good job of sharing its model across non-code environments (reporting, BI, etc.) And it shouldn't. Its not its job.
If I had one complaint with nHibernate it is in the realm of tooling. CodeSmith and MyGeneration templates are fine but they typically only do a object-to-table mapping. Everything else requries that you hand-code the XML. I think nHibernate design tools is where much of the effort for the project should be focused. That's why so many Microsoft developers have latched onto LINQ for SQL and Entity Framework. Its confortable for them to build models visually.
One last note, of the personal attacks I wanted to point out one person who is taking way too much shrapnel: Julia Lerman. I've known Julia for a number of years and I think she is exceptionally talented and very well intentioned. Picking on her because of her visibility in the Entity Framework is shameful. I have never known her to not talk about the warts as well as the benefits and I expect her forthcoming book will do the same. The real shame of this personal attack is that after many years in the community, she has taken on her first book. Writing your first book is a particularly vulnerable time for anyone. Having to weather the hostility towards the Entity Framework when she is just writing about the technology, not taking ownership in its authorship is a tough thing to do. I expect she'll come out the other side fine but it doesn't seem fair to deal with both at the same time.
In case you didn't catch it, I participated in a webcast called geekSpeak. This webcast was hosted by Glen Gordon and Chad Brooks. The topic today was "Silverlight and Line of Business Applications". While geekSpeak's usually focus on hands-on examples of creating code, we took a different tact today and discussed the larger topic of where Silverlight fits in the development ecosystem (at least Microsoft's ecosystem).
For my money, the real benefit in Silverlight is for applications that cross the firewall. This means Line of Business applicaitons are really for B2B and B2C solutions. Unfortunately, what I hear from the community is that people see Silverlight as a solution for porting their desktop and traditional 3-tier applications to the web. Is this a good idea? I don't think so. The problem is that desktop development usually involves business objects that tend to have a direct connection to the database. Moving these sorts of applicaitons to the web means that you need to create an extra layer of communications and serialization. There is a cost both in development and performance for these extra layers.
It comes down to a key question...why are you moving to a web model for your application? If you want to expand the reach of your application to more users and clients (outside your organization), Silverlight is still a great story. Unfortunately many organizations see web applications as a deployment solution. No install, no framework, etc. While clearly this isn't true for Silverlight per se, its also a bad reason to go to a web application. Technlogies like Click-Once and XBAP are a great solution for a better deployment story than traditional desktop applications.
Since I brought up XBAP, let's plug it a bit. I notice that even amongst WPF guys, XBAP is a lost story. If you're not familiar with it, essentially its an in-the-browser WPF applicaitons that is deployed via manifest files (e.g. like ClickOnce). This means you can have the richness of UI, the better data binding story and interactivity that WPF/XAML affords you without having to deal with the limitations of Silverlight. I suggest that many organizations that want to use Silverlight for internal applications (inside the firewall) should be doing XBAP instead.
So what about ASP.NET/AJAX? The big story here is that HTML-based interfaces still have the longest reach of all the Internet enabled applications. HTML just works on many more platforms and browsers than Silverlight or Flash. Before you commit to moving away from HTML-based UI's, spend some time with your server logs. Understand who is really using your existing application before you leave anyone in the dust. A better strategy is often to include fall-back functionality. For example, in my Silverlight Tour website (http://www.silverlight-tour.com), I decided that developers may have Silverlight installed so I wanted to give them a better experience by showing an interactive map of tour stops. But their bosses and accounting departments were unlikely to have it installed. In that case I made a design decision to never prompt to install Silverlight, but instead if it wasn't installed to show a simple table of the classes instead of the Silverlight app. This is a great solution to moving forward without leaving old users in the dust.
Why is Silverlight not a good solution inside the firewall? The two issues are infrastructure and security. In order to build solid line-of-business solutions with Silverlight, you need to have a way to communicate data with the server. Building this infrastructure can be labor intensive, but more importantly adds complexity. More moving parts == more than can go wrong. Security is the second issue. Silverlight (for good reason) is pretty locked down. This means you will need to often learn to work in tighter confines (limited access to storage, no access to file system, registry, ports). If your application is meant to work in trusted scenarios (e.g. Integrated Windows Authentication), the limitations of the high-security environment will be a real limiter.
So what does this all mean? I still think Silverlight is still the solution when you need to *extend* the HTML model in the browser. Line of Business applications across the firewall still need to be web driven in my opinion, but enhancing that story with Silverlight for soutions like data visualization, user interactivity or media is a great solution. While I think that creating whole-browser solutions make sense for some applications, it doesn't for many many more. My fear is that we will move from monolithic desktop apps to monolithic Silverlight apps. The web is still a disconnected model and deciding on building a single huge Silverlight app (instead of page-based functionality) just doesn't make much sense. If you are planning on building one of these monstrocities, please also read my recent blog about linkability in Silverlight:
http://wildermuth.com/2008/06/25/Doesn_t_Anyone_Bookmark_Anymore.aspx
When I teach Silverlight 2, I stress an important lesson that I thought that we (as developers) had learned the importance of linkability of the web. Early usage of Flash was the first time I noticed this. A number of those sites would create nested functionality that never changed the URL. If the URL doesn't change, i can't bookmark it. Most Flash guys learned their lessons pretty quick, but now I am inundated with AJAX driven sites that try hard to not to do post-backs. That's cool, but if the URL doesn't change I can't link to it.
I've noticed this happening a lot with support sites. The first time I saw with an AJAX site was using the Intersoft's Developer Portal (http://www.intersoftpt.com). They treat the developer to a desktop-like experience, but if I can't send a link to my other developers for the latest patch, why bother making it on the web?
The latest is the game Spore's forums. Trying to help a friend figure out why its crashing, I found some good posts on workarounds but the site's address is always http://www.spore.com/forum. What's the point?
This post is a request...a pleading...begging even. Think about the usability of your sites. If it lives on the Internet, it should be linkable. Now if your site doesn't have state, this doesn't apply to you, but for the other 99.999% of the sites out there, don't get too caught up in the frenzy of AJAX or RIA to make your sites usable. The reality is that you can do this with Silverlight, Flash, AJAX or any web page. It might be more work, but the level of frustration for users is well worth your time.
(NOTE: Microsoft is working on a new version of their AJAX toolkit to enable URL changes during partial page updates. This will help some of you, but the rest of you will still need to do some of the hard work yourselves.)
I am surprised when I talk to developers these days and they don't know who Sara Ford is. She's responsible for CodePlex and many open source initiatives at Microsoft. In addition, her blog is an excellent source of information on Visual Studio tricks and features that most of us have never noticed. It is well worth a read. Just announced today, her blog is now available in Russian and Spanish so if English isn't your native tongue, you're in luck there too.
Wonder how I get someone to translate my blog into other languages ;)
If you've used Silverlight 2 much, you probably have already run into the issue with URI's that can be specified in XAML (e.g. Image and MediaElement). When using relative URI's for these elements, Silverlight 2 uses a "Site of Origin" resolution symantic. Instead of resolving the relative URI's based on the website that the Silverlight 2 application is hosted on, it resolves it based on the site of the origin of the application (the .xap file). If the application is hosted on a site (i.e. http://mysite.com) and our .xap file is in a directory (i.e. http://mysite.com/ClientBin), then a relative URI will be resolved based on the locaiton of the .xap file. This means that a relative URI like "/foo.jpg" we resolve to "http://mysite.com/ClientBin/foo.jpg" *not* "http://mysite.com/foo.jpg" as you might expect. In fact, changing this to "../foo.jpg" doesn't change anything. It thinks that the directory of the .xap file is the root of the URI, no matter what you do. Lastly, this also means that if your .xap file is hosted on a site other than your website, these URI's are relatvie to that remote web server, not yours.
These URI's are special because relative URI's look in the .xap file itself first. That's why you can include images in the .xap file and use them with relative URI's in Silverlight 2 without having to have a special syntax to specify the xap file itself. In addition, this syntax is meant to avoid having to learn the cryptic pack:// URI syntax that is used in WPF to retrieve items. So what can we do to simply this?
My initial approach was to try and make a XAML markup extension or something else nearly as arcane, but now I have a simple approach. I have started to place my .xap files at the the root of my web applications. This is in stark contrast to what the tools suggest (e.g. using a ClientBin directory), this means that these relative URI's will act like the root webserver. So far I have not found a drawback to this approach.
To do this you will change the directory from ClientBin to simply blank. For example, when you view the silverlight applicaitons (in the website properties), you can use the "Add" button to link a Silverlight application to your website:
When you add the Silverlight application, make sure and clear the Destination folder:
This will place the .xap files in the root of the web site and therefore relative URI's will resolve just like every other relative URI. Voila!
If you know of a good reason not to do this, please comment below. I am vetting the technique to make sure its a good piece of advice to give.
This week, I will be joining Glen Gordon and Chad Brooks for a GeekSpeak webcast. The Webcast starts at 3pm EST (or noon PST) on Wednesday, June 25th, 2008. We will be discussing Silverlight 2 and its use in so called "Line of Business" applications. Please join us and bring your questions.
If you don't know what a GeekSpeak event is, here is a description straight from Microsoft's website:
MSDN geekSpeak is a fresh kind of webcast series, hosted by Glen Gordon and Lynn Langit of the MSDN Events team. Dispensing with traditional slide decks and scripted demos, geekSpeak brings you industry experts in a talk-radio format. These experts share their knowledge and experience around a particular developer technology.
See you there!
The next Atlanta Geek Dinner has been announced for June 25th, 2008 at Repast in Atlanta. We will be arriving at 6:30pm for scintillating conversation about programming, technology, who's phone is cooler and why we all stopped watching Lost after season one. Everyone is welcome. Please RSVP here:
http://geekdinners.com/dinnerinstance.aspx?id=10
We had a geek dinner tonight in Washington, DC. I can't thank G. Andrew Duthie enough for facilitating the whole night. We got to discuss Silverlight, .NET, Origami, iPhone, Zunes, and everything great in technology. It was a great time to see everyone. Thanks again for a good time.
