In a Perfect World

Fun with Silverlight

2011-10-10T09:22:00.000-07:00

In my previous post, I mentioned a bit about the architecture from a project I was working on. In this post I wanted to mention a couple of the things that we did with Silverlight and how they worked out.

One solution for both silverlight and the client services (run as a console app)

It was nice to have one solution rather than multiple. And changing the start-up type of the project to multiple allowed both apps to run at once.
Debugging was a breeze in either run-time.
There was no way to enforce start-up order/delay to make sure the services were running before starting silverlight. This was rectified by adding some retry logic when connecting to the services.

Sharing of code between the two runtimes (Silverlight and .NET)

We went with a file sharing approach opposed to conditional compiler statements.
Sharing files was a bit of a pain, although with partial classes you could have three implementations. A common version (shared between both), a .NET version, and a Silverlight version.
Resharper bound to one runtime and would not search in the other, i.e. finding usages of a method only returned results from one runtime not both.
Navigating to the file sometimes would go to the link, i.e. alt+shift+L

Rich domain without DTOs, the entities themselves were sent to the Silverlight side.

This got rid of the required set of mappers/builders to translate from server to client and back.
Encapsulation became much more difficult.
Events from the server could be passed as is to the client and would work the same, i.e. no translation/mapping work required.
some navigation properties on the entities (those that created a circular link, like a link back to the parent) could not be serialized requiring some custom logic on the Silverlight side to set them.
When working with a system where events are used, the only time that a domain object is sent to the client is during a query. With commands a domain object is never sent back to the server. This made DTOs a bit heavy weight of a solution.
I would have liked to do something unique with Queries like just return ViewModels directly if possible.

Testing in Silverlight is crappy

Debugging is difficult as you have to start up the silverlight client by running it as a startup project. The error itself has to be closed to then edit the code.
Statlight allowed the tests to be run as part of the build, but this required the build service to be able to interact with the desktop (to launch the silverlight client which then runs the test).
Integration tests proved to be a pain as well as you have to mock out the data returned from the services. This would be similar as pre-populating/seeding a db with data on the server side, but in this case you have to match web service calls and return the correct data. Mocking can be used for this, but with the asynchronous nature it is ugly and difficult to read.

CQRS and Event Sourcing in .NET 4 and Silverlight

2011-10-07T08:03:00.000-07:00

In my latest engagement we built an occasionally connected application that required synchronization, concurrency/conflict resolution, and event driven. Taking all these requirements into account we came up with a solution that utilized commands and event sourcing to satisfy the requirements. From a high-level this architecture looked something like:

Moving through the layers, we start with Silverlight. There was some debate as to use WPF or Silverlight. We went with Silverlight and it made it easier to make a web based version of the applicatoin. The difficulty that this added was another framework. We ended up sharing code between the silverlight projects and .net projects which is a major pain (opposed to compiler directives).

We made extensive use of MVVM and Prism. The view models required event hookups between both the views and the viewmodels as well as from the model to the view models. In our design we used a rich domain that raised events which could be used to trigger changes in the UI.

To achieve this, we had to have an identity map on the silverlight side. Using CQRS, we would query for the object once and then receive events on that object. Any updates to the object would be sent via a command. Our WCF services were quite simple, loads, property changed events, collection changed events, and sending commands.

The silverlight side (OOB) communicated with a small console app that was WCF over TCP. These client services handled queries, commands, and events as IO. For the service binding we used the channel factory which enabled us to use dynamic proxies. Although, the proxies did not change much as there was extensive use of generics to make the signatures of the methods dynamic. To reference objects dynamically from a service call that was bound to a concrete type, we created an object called EntityUID. This contained a type and an id, just enough to uniquely identify the entity. This allowed our service definitions to be quite simple, for example load might be something like: T Load(EntityUID entityUid).

I will post more about the service layer in another post, but from a high level, the service layer was composed using Entity Framework Code First, Unity for dependency injection, the built in .net property changed events and observable collections, SQL CE, and WCF.

Look for more posts on the lessons learned from this architecture as well as some neat tricks to doing things with .net 4.

Why I Miss Pair Programming

2010-12-21T08:20:00.000-08:00

One of the best parts of my job is working with some really great people. People who are at the top of their field and you can learn a lot from. In Agile there is a practice called pair programming, where you pair up with another teammate on a project. One of the biggest criticisms that I have heard about this practice is that it wastes people’s time, since you can’t be twice as productive in terms of raw coding when pairing. Of course the natural response to this criticism is that while you don’t produce twice as much code, you do produce much better code. The pair creates code that is more maintainable and is less prone to errors.

Anyway, getting back to the original subject, I have been out on projects without pair programming now for some time and I can honestly say that I miss it. It is very rewarding to work with someone else who brings a different set of ideas when solving a problem. It becomes magical when it creates something that is far cleverer than what you could accomplish alone.

Of course pair programming doesn’t typically start all roses. Usually it begins with one person being a keyboard hog or at least that is how it feels sometimes. Also, it can feel as though the other person is challenging your ideas and it can put you in a defensive mindset.

I typically try to mitigate the first issue (keyboard hog) by using an approach called ping-pong. Basically one person in the pair is in charge of writing a test which breaks. The other person is then responsible for fixing this test and then creates the next broken test which the first person then has to fix. This not only breaks the monogamy of a one typer show, it also enforces a Test Driven Development approach.

For the second issue, having a feeling of being attacked and adopting a defensive mindset, it comes down to comfort with the other person. There are always more than one way to do things, and adopting the “do the simplest thing that could possibly work” kind of limits that set of ways to do things. However this type of discussion, determining what is the best way to solve a problem, is what supplies the learning experience. After all, most people can create code given pseudo-code. So the best approach is to really talk through each option and try to determine the best solution. When you have a solution that both people think is best, the chances of it working well are that much higher.

The design type banter is what I miss most about Pair Programming. It is exciting to hear alternative solutions, to come up with real reasons on why one solution is better than another, and to try something different, an approach that you might not have thought of or done if you were not pairing.

Sharepoint UserProfileManager Security and Sharing

2010-12-02T09:45:00.000-08:00

For this blog I will look at the Sharepoint UserProfileManager. In particular how to get around user permissions in regards to profile management and to share an instance accross an application.

The user profile manager will always check the users permissions to determine if they have the ability to manage user profiles. This is not feasible for an internet application. Instantiating an instance of the user profile manager is expensive so using a common instance allievates this cost.

To get around the security concerns, there are two things that must be done. First, you must run with elevated privledges. Second you must clear out the httpcontext so the useris not present. This would be something like:

HttpContext.Current = Nothing
SPSecurity.RunWithElevatedPrivileges(AddressOf GetUserProfileManager)

Obviously this is a very simple implementation, for a real one lets add in the instance sharing:

Private ReadOnly Property UserProfileManager() As UserProfileManager
    Get
        If (_userProfileManager Is Nothing) Then
            SyncLock (_syncLock)
                If (_userProfileManager Is Nothing) Then
                    SPSecurity.RunWithElevatedPrivileges(AddressOf GetUserProfileManager)
                End If
            End SyncLock
        End If
        Return _userProfileManager
    End Get
End Property

Private Sub GetUserProfileManager()
    Using systemSite = New SPSite(_site().ID) 'where _site is Func(Of SPSite)
        Dim siteContext As ServerContext = ServerContext.GetContext(systemSite)
        Dim currentContext As HttpContext = HttpContext.Current
        HttpContext.Current = Nothing
        Try
            _userProfileManager = New UserProfileManager(siteContext)
        Finally
            HttpContext.Current = currentContext
        End Try
    End Using
End Sub

Now we are setting a local variable to the instance of the UserProfileManager the first time that we use it. This code assumes a singleton type class hence the multithreading locking.

So this is all fine and dandy, but how do we use the UserProflieManager? Unfortunately even when we use the manager, we still need to cleare out the current HttpContext, i.e.

Public Function Exists(ByVal userName As String) As Boolean Implements IUserInformationSharepointProfileDataAccess.Exists    
    'Get User Profile manager BEFORE setting the current context to nothing
    Dim userProfileManager As UserProfileManager = Me.UserProfileManager

    Dim currentContext As HttpContext = HttpContext.Current
    HttpContext.Current = Nothing
    Try
        Return userProfileManager.UserExists(userName)
    Finally
        HttpContext.Current = currentContext
    End Try
End Function

This exposes a potential issue where we get the UserProfileManager after we set the HttpContext to nothing. This causes issues in the SPSecurity.RunWithElevatedPrivileges method, hence the comment in the code.

With all the changes above, we can now use one instance of the manager for the life of the application and for any user.

Unit Testing With SharePoint

2010-12-02T07:50:00.000-08:00

This article tackles some of the unit and integration testing woes when using the sharepoint object model.

Testing with Sharepoint kind of sucks. First it lacks interfaces making mocking impossible. Second it uses the non-generic functions, like IEnumerable rather than IEnumerable(Of x). Third, it typically returns complex objects from service methods and these complex objects are not DTOs or value objects and require more than a simple new operator to instantiate. Fourth, there are a couple of fundemental objects that are used a lot, SPSite and SPWeb come to mind.

To work around the lack of interfaces, a facade works well. In this example, I am working with the Sharepoint User Profile Object. Lets say we want to get/set values for a users profile.

We would need an interface like this:

Public Interface ISharePointUserProfileFacade
Default ReadOnly Property Item(ByVal propertyName As String) As ISharePointUserProfileValueCollectionFacade
End Interface

Notice that I also need to create a second facade for the valuecollection that is returned from the built-in UserProfileValueCollection. For this example, the interface could look like:

Public Interface ISharePointUserProfileValueCollectionFacade
Inherits IEnumerable
Property Value() As Object
End Interface

Now we have a facade that we can substitute in a mock for when testing.

I will include a quick implementation of the interface for those interested.

Public Class SharePointUserProfile
Implements ISharePointUserProfileFacade

Public Sub New(ByVal userProfile As UserProfile)
_userProfile = userProfile
End Sub

Public ReadOnly Property Item(ByVal propertyName As String) As ISharePointUserProfileValueCollectionFacade Implements ISharePointUserProfileFacade.Item
Get
If String.IsNullOrEmpty(propertyName) Then
Throw New ArgumentException("Null or empty property name specified")
End If

Return New SharePointUserProfileValueCollection(_userProfile(propertyName))
End Get
End Property

In this code we can create the facade from a UserProfile Sharepoint object. Now for the value collection:

Public Class SharePointUserProfileValueCollection
Implements ISharePointUserProfileValueCollectionFacade

Public Sub New(ByVal collection As UserProfileValueCollection, ByVal _trackChangeDelegate As TrackChange)
_collection = collection
_trackChange = _trackChangeDelegate
End Sub

Public Property Value() As Object Implements ISharePointUserProfileValueCollectionFacade.Value
Get
Return _collection.Value
End Get
Set(ByVal value As Object)
If (_collection.Value Is Nothing AndAlso (Not value Is Nothing)) OrElse (Not _collection.Value Is Nothing AndAlso Not _collection.Value.Equals(value)) Then
' track change
If Not _trackChange Is Nothing Then
_trackChange(_collection.Property.Name, value)
End If
End If
_collection.Value = value
End Set
End Property
End Class

In this example, the use of a facade allows additional behavior to existing value collection object. I have added a change tracker to the set property fairly easily.

Ruby XML Builder in C# .NET 4.0

2010-05-11T13:06:00.000-07:00

Now that .NET has the power of a dynamic language the first comparison is going to be with the powerhouses that are currently gaining momentum. I decided to implement something similar to the Builder library in Ruby. It seemed like a fun starting point that would not be over-involving.

Before I go too far, lets see an example in ruby, although don't worry about the ruby itself as this is a blog more on .NET 4.0

...
xml.contacts do
xml.contact(:type => "work") do
xml.name("Joe Smith")
...

Basically this uses missing methods to add elements to an XML document. For attributes, it uses hashes. For nesting elements, it uses blocks of code.

Some might say that Linq to XML already implemented a simple XML document builder with it's functional construction approach. This is a little different from that.

The first hurdle is types and syntax. Hashes translate to KeyValuePairs in a dictionary which is a bit messy done in a parameter call. Blocks of code, lambdas in .NET require themselves to be cast as a delegate or syntax trees which again is messy. I went with the easy approach, strings for the element/value pairs, string for the value, and use nested calls rather than code blocks. So with all these changes in place here is a sample use of the XmlBuilder:

dynamic xmlBuilder = new XmlBuilder();
var result = xmlBuilder.Contacts(
         xmlBuilder.Contact("type", "work",
             xmlBuilder.Name("Joe Smith"),
             xmlBuilder.Phone("type", "work", "(123) 456-7890"),
             xmlBuilder.Address("type", "home",
                 xmlBuilder.Street("123 Main St."),
                 xmlBuilder.City("SpringField"))));

Console.WriteLine("XML: \n" + result.ToString());

It is not too much worse than the Ruby version which is a win with a more verbose language like C#. Yes, there were a few concessions i.e. not using hashes for elements.

So now that we have our requirements lets look at the code necessary to meet them.

The first thing that we need is to inherit from DynamicObject and override the TryInvokeMember() function. This allows us to always accept method calls which do not match real methods on the object. This is done as follows:

class XmlBuilder : DynamicObject
{
  public override bool TryInvokeMember(InvokeMemberBinder binder, object[] args, out object result)
  {
      //parse arguments
      //Create XML Document
      //Set Result
      //Return true (handled method)
  }
}

Simple enough, the next hurdle is going to be argument parsing. This overload puts all our arguments in an object array, not all that helpful. Now we will need to do some casting and parsing. In our case we are looking to break up the elements from the nested XDocuments constructed from the nested calls, and the optional value parameter. Something like the following should work:

private dynamic ParseArguments(object[] arguments)
{
var documents = new List();
var strings = new List();
var attributes = new List();
string text = null;

foreach (var arg in arguments)
{
    XDocument xDocArgument;
    string stringArgument;
    if (CastAs(arg, out xDocArgument))
        documents.Add(xDocArgument);
    else if (CastAs(arg, out stringArgument))
        strings.Add(stringArgument);
}

if (strings.Count % 2 == 1)
{
    text = strings.Last();
    strings.RemoveAt(strings.Count - 1);
}

for (int i = 0; i <>        return new { Documents = documents, Attributes = attributes, Text = text };
    }

    private bool CastAs(object value, out T castedValue)
    {
        if (value is T)
        {
            castedValue = (T)value;
            return true;
        }
        castedValue = default(T);
        return false;
    }
}

We start by breaking up the arguments into to lists then further separate them into the three parameters. Casting ugliness was a big motivator to the move to dynamic types, and you can see how most of the code is just concerned with typing issues. I did get to sneak in an anonymous object as the return value.

Now that we have the parameters, the rest is simple:

public override bool TryInvokeMember(InvokeMemberBinder binder, object[] args, out object result)
{
  var arguments = ParseArguments(args);
  XElement rootElement = new XElement(binder.Name, arguments.Text, arguments.Attributes);
  foreach (XDocument xDocument in arguments.Documents)
      rootElement.Add(xDocument.FirstNode);

  result = new XDocument(rootElement);
  return true;
}

.NET 4.0 Dynamics and Linq Anonymous Types

2010-05-10T14:56:00.000-07:00

I have been trying to find an occassion in an existing application where Dynamics would be a good fit. The big problem is that the existing application is strongly-typed. Use of dynamic methods doesn't really exist. Until I started looking at some Linq usage. Linq uses anonymous types quite a bit. This was fine as long as the type was used locally, it could not be passed around and used. What a perfect fit for Dyanmics. Here is an example:

private static string[] primaryColors = new string[] { "Blue", "Red" };
private static string[] secondaryColors = new string[] { "Black", "Silver" };

static void Main(string[] args)
{
  foreach (var result in GetColorList())
  {
      Console.WriteLine("Color Selection {0} and {1}", result.PrimaryColor, result.SecondaryColor);
  }
}

public static IEnumerable GetColorList()
{
  return from primaryColor in primaryColors
         from secondaryColor in secondaryColors
         select new { PrimaryColor = primaryColor, SecondaryColor = secondaryColor };
}

Here I can access all of the properties on the list with the use of dynamic for the anonymous type. Of course this will not be as fast as static code, returning an enumeration of strongly typed objects but it is a good illustration of dynamics in action.