Shannon Braun and I were interviewed by Jeff Brand, the Twin Cities .NET Developer Evangelist for Microsoft. Jeff does a podcast titled Spaghetti Code, and we discussed our experiences at the MIX 08 conference earlier this spring.

http://www.slickthought.net/post/Spaghetti-Code-Podcast---Recapping-MIX-with-Rocky-Lhotka-and-Shannon-Braun.aspx

Silverlight 2.0 doesn't have an equivalent to the BinaryFormatter or NetDataContractSerializer. This makes some things quite challenging - in my case building CSLA Light. CSLA .NET requires high-fidelity serialization both for implementation of the Clone() operation and within the data portal.

I've been working on building a Silverlight-compatible equivalent to the BinaryFormatter/NDCS. It turns out to be quite hard due to the limitations of the Silverlight sandbox.

For example, Silverlight does have reflection, even against private fields. However, you can only get or set a private field with code inside the same class as the field declaration. You can't get/set a field from another object, or even from a base class or subclass. The reflection call must be in the same class!

At this point I have a prototype serializer that works in some limited scenarios. It is a starting point. Some aspects aren't ideal, but may just be the way they are to get around how Silverlight works. Still, the end result is relatively cool.

To use the serializer:

1. Build the Csla project (it is a Silverlight Class Library) and reference it from your Silverlight application
2. In your business class, add a using/Imports statement for Csla.Serialization
3. Add the Serializable attribute to your class
4. You class must also either inherit from MobileObject or implement the IMobileObject interface (I recommend using inheritance, as otherwise you'll have to write a lot of nasty code)
5. You must override GetValue() and SetValue() in your class - these methods are called by the MobileFormatter so you can reflect against your private fields. See the example below to see how this works
6. You can now use the MobileFormatter much like you would the BinaryFormatter. See the example below

The MobileFormatter is far from complete. But it can serialize/deserialize fields of an object that contain primitive types (anything that works with Convert.ChangeType()). And it handles references to other serializable objects, both single objects and lists of serializable objects (if they implement IMobileObject or inherit from MobileList<T> ).

I'm pretty sure it can't handle arrays, nor can it handle any list type other than (effectively) List<T>. I'm not sure what it will do with enums or other types - just haven't gotten that far yet.

Here's a serializable object:

using System;
using Csla.Serialization;

namespace SilverlightApplication1
{
  [Serializable]
  public class Person : MobileObject
  {
    #region Serialization

    protected override object GetValue(System.Reflection.FieldInfo field)
    {
      if (field.DeclaringType == typeof(Person))
        return field.GetValue(this);
      else
        return base.GetValue(field);
    }

    protected override void SetValue(System.Reflection.FieldInfo field, object value)
    {
      if (field.DeclaringType == typeof(Person))
        field.SetValue(this, value);
      else
        base.SetValue(field, value);
    }

    #endregion

    public string Name { get; set; }

    [NonSerialized]
    private DateTime _birthdate;
    public DateTime BirthDate
    {
      get { return _birthDate; }
      set { _birthdate = value; }
    } 
  }
}

And here's how to serialize/deserialize the object:

var p = new Person();

var formatter = new Csla.Serialization.MobileFormatter();
var buffer = new System.IO.MemoryStream();
formatter.Serialize(buffer, p);

buffer.Position = 0;
var copyOfP = (Person)formatter.Deserialize(buffer);

Though it is unfortunate that every business class must implement GetValue() and SetValue(), I think that is a relatively small price to pay to get nearly the same capability as we have in .NET with the BinaryFormatter in terms of cloning objects, and more importantly in terms of serializing them across the network with full fidelity.

Someone on the CSLA .NET discussion forum recently asked what new .NET 3.5 features I used in CSLA .NET 3.5. The poster noted that there are a lot of new features in .NET 3.5, which is true. They also included some .NET 3.0 features as "new", though really those features have now been around for 15 months or so and were addressed in CSLA .NET 3.0. CSLA .NET 3.0 already added support for WCF, WPF and WF, so those technologies had very little impact on CSLA .NET 3.5.

My philosophy is to use new technologies only if they provide value to me and my work. In the case of CSLA .NET this is extended slightly, such that I try to make sure CSLA .NET also supports new technologies that might be of value to people who use CSLA .NET.

While .NET 3.5 has a number of new technologies at various levels (UI, data, languages), many of them required no changes to CSLA to support. I like to think this is because I'm always trying to look into the future as I work on CSLA, anticipating at least some of what is coming so I can make the transition smoother. For example, this is why CSLA .NET 2.0 introduced a provider model for the data portal - because I knew WCF was coming in a couple years and I wanted to be ready.

Since CSLA .NET already supported data binding to WPF, Windows Forms and Web Forms, there was no real work to do at the UI level for .NET 3.5. I actually removed Csla.Wpf.Validator because WPF now directly supplies that behavior, but I really didn't add anything for UI support because it is already there.

Looking forward beyond 3.5, it is possible I'll need to add support for ASP.NET MVC because that technology eschews data binding in favor of other techniques to create the view - but it is too early to know for sure what I'll do in that regard.

Since CSLA .NET has always abstracted the business object concept from the data access technique you choose, it automatically supported LINQ to SQL (and will automatically support ADO.NET EF too). No changes required to do that were required, though I did add Csla.Data.ContextManager to simplify the use of L2S data context objects (as a companion to the new Csla.Data.ConnectionManager for raw ADO.NET connections). And I enhanced Csla.Data.DataMapper to have some more powerful mapping options that may be useful in some L2S or EF scenarios.

LINQ to Objects did require some work. Technically this too was optional, but I felt it was critical, and so there is now "LINQ to CSLA" functionality provided in 3.5 (thanks to my colleague Aaron Erickson). The primary feature of this is creating a synchronized view of a BusinessListBase list when you do a non-projection query, which means you can data bind the results of a non-projection query and allow the user to add/remove items from the query result and those changes are also reflected in the original list. As a cool option, LINQ to CSLA also implements indexed queries against lists, so if you are doing many queries against the same list object you should look into this as a performance booster!

So all that's left are some of the language enhancements that exist to support LINQ. And I do use some of them - mostly type inference (which I love). But I didn't go through the entire body of existing code to use the new language features. The risk of breaking functionality that has worked for 6-7 years is way too high! I can't see where anyone would choose to take such a risk with a body of code, but especially one like CSLA that is used by thousands of people world-wide.

That means I used some of the new language features in new code, and in code I had to rework anyway. And to be honest, I use those features sparingly and where I thought they helped.

I think trying to force new technologies/concepts/patterns into code is a bad idea. If a given pattern or technology obviously saves code/time/money or has other clear benefits then I use it, but I try never to get attached to some idea such that I force it into places where it doesn't fit with my overall goals.

VS Live Orlando is coming up soon, and I'll be speaking at the event.

I'm giving a presentation on the use of OO concepts, WCF services and Silverlight working together to build compelling web applications.

And I'm giving a full-day workshop covering a broad range of .NET technologies, focused on transitioning from the .NET 2.0 world forward into the .NET 3.5 world. Not surprisingly, I use CSLA .NET as part of this workshop, though the primary focus is on making sense out of all the different technologies you might use for creating your applications.

As a track chair and speaker for VS Live, I am able to provide you with a special discount code. Register for VS Live using the code SOLHO and save $300!

Dunn Training is holding a three day CSLA .NET training class in Toronto, May 5-7. Dunn's three day class is a great way to jumpstart your use of CSLA .NET, and Toronto is a fun city, so this is a great opportunity!

Microsoft Tech Ed 2008 is coming up in early June. This year they are splitting it into two parts: IT Pro and Developer, each of which gets a week. I think this is a good move, as it allows the Developer week to be focused on topics developers care about. They've done this for a couple years now in Europe and it has been successful there.

The developer week is June 3-6.

I'm a co-chair for the Developer Tools track, which covers Visual Studio, all the languages and related topics. I think we put together a great set of speakers and topics in this track, so I'm very excited about it!

I'm also one of the featured speakers, and you can see details about all the featured speakers in a nice little Silverlight app.

I recently participated in a webcast covering SOA, REST and various related topics. You can listen to it here

http://www.slickthought.net/post/Minneapolis-Developer-Roundtable-Podcast---Talking-REST.aspx

I have a question (helping a colleague do some research) for all .NET VB developers.

Do you use late binding in VB? If so, how/why do you use it? What are the scenarios where you find it of value?

I'll start this off with my own observations:

I use late binding when getting data of a given shape from unknown types.

For example, you can write a nice bit of reusable data access code that accepts data from a web service, LINQ object, etc. by using late binding. You can’t easily do this without late binding in fact, because the types of the objects are different even though their shapes are the same.

That dynamic interface concept that got dropped from VB9 would address this issue in a better way, but late binding makes it work too.

I also use late binding when creating some generic types. There are cases where generics and casting are problematic, but converting a value to type Object first allows you to do a cast or operation that wouldn’t otherwise be allowed. I don’t know if this is “late binding” as such, but it is a useful technique!

I have used late binding when dynamically loading an assembly for interaction. Ideally you’d require the assembly author to implement one of your interfaces, but that’s not always possible, and late binding is a particularly nice way to get “polymorphic” access to multiple assemblies that you don’t control.

What about you?