Kyle McClellan

Unit Testing a WCF RIA DomainService: Part 3, The DomainServiceTestHost

2011-08-18T15:10:30Z

In this thrilling conclusion to my series on unit testing, I’ll show you how to use the DomainServiceTestHost to test your DomainServices. In parts one and two I showed you how to extract external dependencies using the IDomainServiceFactory and how to use the Repository Pattern. Now that all the groundwork is out of the way, I’ll show you how to test your business logic.

The DomainService

The DomainService we’re testing looks like this.

  public class BookClubDomainService : RepositoryDomainService
  {
    public BookClubDomainService(
      IUnitOfWork unitOfWork,
      IBookRepository bookRepository,
      ILibraryService libraryService,
      IApprovalSystem approvalSystem) { ... }

    // Test 1: Operation should return all books
    // Test 2: Operation should return books with categories
    // Test 3: Operation should return books ordered by BookID
    public IQueryable<Book> GetBooks() { ... }

    // Test 1: Operation should return all books for category
    // Test 2: Operation should return books ordered by BookID
    public IQueryable<Book> GetBooksForCategory(int categoryId) { ... }

    // Test 1: Operation should insert book
    // Test 2: Operation should set the added date
    // Test 3: Operation should request approval for book with invalid ASINs
    // Test 4: Operation should request approval for book not yet published
    public void InsertBook(Book book) { ... }

    // Test 1: Operation should update book
    // Test 2: Operation should return validation errors
    public void UpdateBook(Book book) { ... }

    // Test 1: Operation should update book
    // Test 2: Operation should update the added date
    [Update(UsingCustomMethod = true)]
    public void AddNewEdition(Book book) { ... }

    // Test 1: Operation should delete book
    // Test 2: Operation should require authentication
    [RequiresAuthentication]
    public void DeleteBook(Book book) { ... }

    // Test 1: Operation should return the most recent added date
    public DateTime GetLatestActivity() { ... }
  }

It has the standard Query, Insert, Update, and Delete operations in addition to custom Query, Update, and Invoke(/Service) operations. The constructor accepts a number of parameters; each representing an external dependency in the code. I’ve labeled each method with the tests that we’ll write against it so we don’t have to know the details of the implementation (they’re in the sample, I’m just skipping them in the post).

The DomainServiceTestHost

The DomainServiceTestHost is a new class in the Microsoft.ServiceModel.DomainServices.Server.UnitTesting assembly (now on NuGet and soon to be shipping with the Toolkit). It’s designed to help you test individual DomainService operations. The API falls closely in-line with DomainService conventions (and may help clarify them if you’re still a little hazy). For instance, the test host has a Query method for retrieving data, and Insert, Update, and Delete methods for modifying it.

In addition to standard operation support, the test host makes it simple to test validation and authorization. For each standard signature in the DomainServiceTestHost, there is a TryXx variant that makes it easy to capture validation errors. For instance, Query is paired with TryQuery and Insert with TryInsert. Also, each time you create a test host, you can pass an IPrincipal into the constructor that the operations should be run with. This makes it easy to cycle through a number of test users as you validate your authorization metadata. Finally, the test host can be created with a factory method that it uses to instantiate a DomainService. This allows you to initialize a DomainService with test-specific dependencies.

Testing a DomainService

Finally we’re getting to the good part. In this section, I’ll walk you through the steps necessary to unit test your business logic. First, we’ll initialize the local variables we’ll use with each test.

  [TestInitialize]
  public void TestInitialize()
  {
    this._libraryService = new MockLibraryService();
    this._approvalSystem = new FakeApprovalSystem();
    this._unitOfWork = new FakeUnitOfWork();
    this._bookRepository = new MockBookRepository();

    this._domainServiceTestHost =
      new DomainServiceTestHost<BookClubDomainService>(
        this.CreateDomainService);
  }

  private BookClubDomainService CreateDomainService()
  {
    return new BookClubDomainService(
             this._unitOfWork,
             this._bookRepository,
             this._libraryService,
             this._approvalSystem);
  }

As you can see, I’ve written simple mock/fake/stub types for each dependency. I discussed the MockBookRepository a little in my previous post. For the context of the following tests, it’s important to point out that I’ve initialized the repository with an initial set of data. The other three are just simple test implementations. Also, I’ve provided a CreateDomainService method that I can pass to the test host that initializes my BookClubDomainService with the test dependencies. If you’re not familiar with the Visual Studio testing, the [TestInitialize] method will get called before the start of each test.

Starting with something simple, we’ll take a look at the test for the default query.

  [TestMethod]
  [Description("Tests that the GetBooks query returns all the books")]
  public void GetBooks_ReturnsAllBooks()
  {
    IEnumerable<Book> books = this._domainServiceTestHost.
                                Query(ds => ds.GetBooks());

    Assert.AreEqual(
      this._bookRepository.GetBooksWithCategories().Count(), books.Count(),
      "Operation should return all books");
  }

In this method, we’re asking the test host to return the results of the query. The ‘ds’ parameter in the lambda is the instance of the DomainService we’re testing. Since the IntelliSense for the query operation is a little verbose (as is anything where the Expression type shows up), I’ll give you another sample so you get the hang of it. This time we’re testing the custom query.

  [TestMethod]
  [Description(
     "Tests that the GetBooksForCategory query orders books by BookID")]
  public void GetBooksForCategory_OrderedByBookID()
  {
    int categoryId = this._bookRepository.GetTable<Category>().
                       First().CategoryID;

    IEnumerable<Book> books = this._domainServiceTestHost.Query(
                                ds => ds.GetBooksForCategory(categoryId));

    Assert.IsTrue(books.OrderBy(b => b.BookID).SequenceEqual(books),
      "Operation should return books ordered by BookID");
  }

In this snippet we’re passing a local variable to the query operation, but everything else is pretty much the same. We’ve gotten the returned collection and now we’re verifying that it is in sorted order.

Tests for Insert, Update, and Delete operations are just as easy to write. Just calling the method on the host will redirect to the corresponding operation in your DomainService.

  [TestMethod]
  [Description("Tests that the InsertBook operation inserts a new book")]
  public void InsertBook_InsertsNewBook()
  {
    int categoryId = this._bookRepository.GetTable<Category>().
                       First().CategoryID;

    Book book = new Book
    {
      ASIN = "1234567890",
      Author = "Author",
      CategoryID = categoryId,
      Description = "Description",
      PublishDate = DateTime.UtcNow.Subtract(TimeSpan.FromDays(1)),
      Title = "Title",
    };

    this._domainServiceTestHost.Insert(book);

    Assert.IsTrue(book.BookID > 0,
      "New book should have a valid BookID");

    Book addedBook = this._bookRepository.GetEntities().
                       Single(b => b.BookID == book.BookID);

    Assert.IsNotNull(addedBook,
      "Operation should insert book");
  }

To rephrase what I said above, calling Insert on the test host with a Book calls into our DomainService operation, InsertBook. As you can see, at the end of this test our new book has been added to the repository.

In addition to Query, Insert, Update, and Delete methods, Named Updates and Invoke operations are also supported. In both cases, the syntax is very similar to testing a Query.

  this._domainServiceTestHost.Update(
    ds => ds.AddNewEdition(book), original);

  DateTime result = this._domainServiceTestHost.Invoke(
    ds => ds.GetLatestActivity());

AddNewEdition updates the book and runs custom business logic and GetLatestActivity returns a DateTime related to the newest book. Again, the ‘ds’ parameter in the lambda expression refers to the DomainService being tested.

Testing Validation and Authorization

Testing validation and authorization metadata for a DomainService operation can be just as important as testing the business logic. A unit test suite verifying authorization and validation would be a great tool to prevent service security regressions.

Validation is fairly straightforward to test. Instead of using the test host methods I’ve already described, you should use their TryXx variants.

  [TestMethod]
  [Description("Tests that the UpdateBook operation returns 
     validation errors when passed an invalid book")]
  public void UpdateBook_SetsValidationErrors()
  {
    Book original = this._bookRepository.GetEntities().First();
    Book book = new Book
    {
      AddedDate = original.AddedDate,
      ASIN = "Invalid!",
      Author = original.Author,
      BookID = original.BookID,
      Category = original.Category,
      CategoryID = original.CategoryID,
      Description = original.Description,
      PublishDate = original.PublishDate,
      Title = original.Title,
    };

    IList<ValidationResult> validationErrors;
    bool success = this._domainServiceTestHost.TryUpdate(
                     book, original, out validationErrors);

    Assert.IsFalse(success,
      "Operation should have validation errors");
    Assert.AreEqual(1, validationErrors.Count,
      "Operation should return validation errors");
    Assert.IsTrue(validationErrors[0].MemberNames.Single() == "ASIN",
      "Operation should return a validation error for 'ASIN'");
  }

This test calls into UpdateBook with invalid data and then verifies the resulting validation errors are ones we expect.

Authorization tests follow a different approach. Instead of using a different test host method, they set a custom principal that will be used when calling the DomainService operation. While the test host defaults to an anonymous user, an alternate constructor allows you to specify the user that is interesting for your test case.

  this._domainServiceTestHost = 
    new DomainServiceTestHost<BookClubDomainService>(
      this.CreateDomainService,
      BookClubDomainServiceTest.authenticatedUser);

Conclusion

To sum it all up, the DomainServiceTestHost in combination with an IDomainServiceFactory and the Repository pattern makes it simple to unit test your DomainServices in an isolated and reliable fashion. Also, since the test host is just a .NET type, it should be compatible with any and all test tools and frameworks you feel like using it with. Hopefully this series gave you a good overview of DomainService unit testing. If you have any questions or feature requests, please send them my way. Thanks.

[A Note on the DomainServiceTestHost]

As of the initial release of this test host, there may still be a few edge cases for association and composition change sets that are not supported. If you find any, please let me know so I can put together a scenario for a subsequent release.

Unit Testing Series

Unit Testing a WCF RIA DomainService: Part 2, The Repository Pattern

2011-08-18T15:10:17Z

This is part two in a series I’m writing about how to unit test your DomainServices. In part one, I discuss how you could use an IDomainServiceFactory to factor external dependencies out of your code. Continuing along the same lines of thinking, I will use this post to discuss factoring out the database dependency as well. In general, factoring out external dependencies will increase both the isolation and consistency of your tests.

The pattern I’m using to factor out external dependencies is called the Repository Pattern. It’s well-known and comes in many variations. The variation I’ve chosen here is one that fits quite well with the way RIA consumes and Entity Framework ObjectContext. If you’re using a different data-access technology, feel free to modify this pattern until you get something that works for your scenario.

A Repository Sample

Before I jump into the Repository API or the DomainService setup, I’d like to show what introducing a repository might do to standard DomainService operations. Here are a few operations written directly against an ObjectContext.

  // Test 1: Operation should return all books
  // Test 2: Operation should return books with categories
  // Test 3: Operation should return books ordered by BookID
  public IQueryable<Book> GetBooks()
  {
    return this.ObjectContext.Books.Include("Category").
             OrderBy(b => b.BookID);
  }

  // Test 1: Operation should return all books for category
  // Test 2: Operation should return books ordered by BookID
  public IQueryable<Book> GetBooksForCategory(int categoryId)
  {
    return this.ObjectContext.Books.
             Where(b => b.CategoryID == categoryId).OrderBy(b => b.BookID);
  }

  // Test 1: Operation should update book
  // Test 2: Operation should return validation errors
  public void UpdateBook(Book book)
  {
    this.ObjectContext.Books.AttachAsModified(
      book, this.ChangeSet.GetOriginal(book));
  }

Upon introducing a repository into this code, the operations will be slightly different.

  // Test 1: Operation should return all books
  // Test 2: Operation should return books with categories
  // Test 3: Operation should return books ordered by BookID
  public IQueryable<Book> GetBooks()
  {
    return this._bookRepository.GetBooksWithCategories().
             OrderBy(b => b.BookID);
  }

  // Test 1: Operation should return all books for category
  // Test 2: Operation should return books ordered by BookID
  public IQueryable<Book> GetBooksForCategory(int categoryId)
  {
    return this._bookRepository.GetEntities().
             Where(b => b.CategoryID == categoryId).OrderBy(b => b.BookID);
  }

  // Test 1: Operation should update book
  // Test 2: Operation should return validation errors
  public void UpdateBook(Book book)
  {
    this._bookRepository.Update(
      book, this.ChangeSet.GetOriginal(book));
  }

By-and-large we’ve preserved the existing implementation. However, you can now see we don’t have a direct dependency on ObjectContext. Instead all interaction is funneled through the book repository. Doing this will allow us to introduce a mock repository implementation at test time which will allow us to test without any dependency on a database.

The Repository API

I’m going to abbreviate the API I show in this post. There are more interesting types and methods in the sample but I want to keep the conversation here focused. The first type we should look at is the IRepository<T> interface.

  public interface IRepository<T> : IRepository
  {
    IQueryable<T> GetEntities();
    void Insert(T entity);
    void Update(T entity, T original);
    void Delete(T entity);
  }

A repository is a simple type that surfaces methods for the Query, Insert, Update, and Delete operations that commonly show up in DomainServices. Also, the repository interface has a per-type affinity. Specifically, you’d have a separate instance for each root entity type (as a side note, this felt a little verbose to me, but also worked nicely. I’ll let you make the final call as to whether it’s worth the extra typing).

Here’s a partial Repository implementation using Entity Framework.

  public class Repository<T> : IRepository<T> where T : EntityObject
  {
    public virtual IQueryable<T> GetEntities()
    {
      return this.ObjectSet;
    }

    public virtual void Insert(T entity)
    {
      if (entity.EntityState != EntityState.Detached)
      {
        this.ObjectContext.ObjectStateManager.
          ChangeObjectState(entity, EntityState.Added);
      }
      else
      {
          this.ObjectSet.AddObject(entity);
      }
    }
  }

As you can see, the repository contains the familiar code required to work against the EF ObjectContext and ObjectSet.

The next class to look at is a derived repository interface. As you may have noticed already, our book repository has a GetBooksWithCategories method that isn’t in the base interface.

  public interface IBookRepository : IRepository<Book>
  {
    IQueryable<Book> GetBooksWithCategories();
  }

The concrete implementation of this method will show us why it’s interesting.

  public class BookRepository : Repository<Book>, IBookRepository
  {
    public BookRepository(BookClubEntities objectContext)
        : base(objectContext)
    {
    }

    public IQueryable<Book> GetBooksWithCategories()
    {
        return this.ObjectSet.Include("Category");
    }
  }

Specifically, we’ve used the Include method on ObjectSet. Since the include method is specific to entity framework, I’ve placed it behind the repository interface.

The UnitOfWork API

Both DomainServices and Repositories work on the principal that you can make a lot of changes and then submit them all as a single unit-of-work. To facilitate this, our Repository pattern also provides an IUnitOfWork interface.

  public interface IUnitOfWork
  {
    void Save();
  }

Simple. Now we just need to make sure it is called when our DomainService is ready to persist changes. Luckily, the DomainService base class provides a virtual protected method to allow us to do just that.

  // Test 1: Unit of work should be saved
  protected override bool PersistChangeSet()
  {
    this.UnitOfWork.Save();
    return true;
  }

Finally, we need to make sure the unit-of-work can be used to persist the changes to our Entity Framework model. To do this, we can use a partial class to implement the interface on BookClubEntities.

  public partial class BookClubEntities : IUnitOfWork
  {
    public void Save()
    {
      this.SaveChanges();
    }
  }

Now we’ll need to take a look at how all these pieces are wired up.

A DomainService Using a Repository

Like I showed in my previous post, we’ll need to pass the repository to the DomainService’s constructor.

  public BookClubDomainService(
    IUnitOfWork unitOfWork,
    IBookRepository bookRepository,
    ILibraryService libraryService,
    IApprovalSystem approvalSystem)
    : base(unitOfWork, bookRepository) 
  {
    if (bookRepository == null)
    {
      throw new ArgumentNullException("bookRepository");
    }
    if (libraryService == null)
    {
      throw new ArgumentNullException("libraryService");
    }
    if (approvalSystem == null)
    {
      throw new ArgumentNullException("approvalSystem");
    }

    this._bookRepository = bookRepository;
    this._libraryService = libraryService;
    this._approvalSystem = approvalSystem;
  }

You can refer back to my previous post on how to create and bootstrap an IDomainServiceFactory. I won’t repeat the information here, but I’ll give you a quick look at the factory code that creates the DomainService.

  public class BookClubDomainServiceFactory : IDomainServiceFactory
  {
    public DomainService CreateDomainService(
      Type domainServiceType, DomainServiceContext context)
    {
      DomainService domainService;
      if (typeof(BookClubDomainService) == domainServiceType)
      {
        BookClubEntities bookClubEntities = new BookClubEntities();
        domainService = new BookClubDomainService(
          bookClubEntities,
          new BookRepository(bookClubEntities), 
          new LibraryService(),
          new ApprovalSystem());
      }
      else
      {
        domainService = (DomainService)
          Activator.CreateInstance(domainServiceType);
      }

      domainService.Initialize(context);
      return domainService;
    }
  }

Finally, we need to set the BookClubDomainService to provide the correct metadata about the types it supports. Since we’re returning Entity Framework types, we’ll need to use the LinqToEntitiesDomainServiceDescriptionProviderAttribute.

  [LinqToEntitiesDomainServiceDescriptionProvider(
     typeof(BookClubEntities))]
  public class BookClubDomainService : RepositoryDomainService { ... }

Also, you’ll notice I’ve created a RepositoryDomainService base class to encapsulate some of the common Repository concerns. With all these pieces together, it becomes a simple matter to write DomainService operations.

  // Test 1: Operation should return all books
  // Test 2: Operation should return books with categories
  // Test 3: Operation should return books ordered by BookID
  public IQueryable<Book> GetBooks()
  {
    return this._bookRepository.GetBooksWithCategories().
             OrderBy(b => b.BookID);
  }

Testing With a Repository

Though I plan to save most of this for the next post, it’s worth looking at the MockRespository we’ll use for testing.

  public class MockRepository<T> : IRepository<T>
  {
    private readonly Dictionary<Type, IList> _entities =
      new Dictionary<Type, IList>();

    public List<TEntity> GetTable<TEntity>() { ... }

    public virtual IQueryable<T> GetEntities()
    {
      return this.GetTable<T>().AsQueryable();
    }

    public virtual void Insert(T entity)
    {
      this.GetTable<T>().Add(entity);
    }
  }

The mock repository allows us to populate our table with default data before a test and check the updated contents of the table after the test.

  private class MockBookRepository : MockRepository<Book>, IBookRepository
  {
    public MockBookRepository()
    {
      this.GetTable<Book>().AddRange(new []
      {
        new Book
        {
          AddedDate = DateTime.UtcNow,
          ASIN = "1234567890",
          Author = "Author",
          BookID = 1,
          ...
        },
        ...
      });
    }
  }

Now, when we create our DomainService in our tests, we can pass an instance of MockBookRepository in instead of our real implementation. Using a repository like this in our tests improves the isolation and consistency. In the last post in this series on testing, I will finally show how to write unit tests for your DomainServices.

Unit Testing Series

Unit Testing a WCF RIA DomainService: Part 1, The IDomainServiceFactory

2011-08-18T15:06:00Z

I’ve always been a proponent of driving product quality through unit testing. Regardless of the specific testing methodology, I enjoy the confidence a rich suite of tests can bring to product and application development. For WCF RIA developers, I wanted to start a three-part series on how to test the business logic that resides at the core of your application; your DomainService operations. During this series, I’ll identify patterns, practices, and tools that make testing your DomainServices simple (and maybe even fun?).

The first step to making your DomainService testable is to identify the external dependencies.

A DomainService with Dependencies

We’ll start by looking at a service that has both business logic and dependencies. I’ve authored it in a pretty straightforward manner so I can highlight specific changes that will improve testability.

  public class BookClubDomainService :
    LinqToEntitiesDomainService<BookClubEntities>
  {
    private readonly LibraryService _libraryService = new LibraryService();
    private readonly ApprovalSystem _approvalSystem = new ApprovalSystem();

    // Test 1: Operation should return all books
    // Test 2: Operation should return books with categories
    // Test 3: Operation should return books ordered by BookID
    public IQueryable<Book> GetBooks()
    {
      return this.ObjectContext.Books.Include("Category").
               OrderBy(b => b.BookID);
    }

    // Test 1: Operation should insert book
    // Test 2: Operation should set the added date
    // Test 3: Operation should request approval for book with invalid ASINs
    // Test 4: Operation should request approval for book not yet published
    public void InsertBook(Book book)
    {
      if ((book.EntityState != EntityState.Detached))
      {
        this.ObjectContext.ObjectStateManager.
          ChangeObjectState(book, EntityState.Added);
      }
      else
      {
        this.ObjectContext.Books.AddObject(book);
      }

      book.AddedDate = DateTime.UtcNow;

      if (!this._libraryService.IsAsinValid(book.ASIN))
      {
        this._approvalSystem.
          RequestApproval(book.Author, book.Title, book.PublishDate);
      }
      else if (book.PublishDate > book.AddedDate)
      {
        this._approvalSystem.RequestApproval(book.ASIN);
      }
    }
  }

A quick look at this service should reveal three concrete dependencies. First, we’re using an Entity Framework ObjectContext to talk to a database. We also have a dependency on an external service, LibraryService, and an internal subsystem, ApprovalSystem. The ObjectContext is a unique case which I’ll tackle in the next post, so for now let’s look at what we can do with the LibraryService and ApprovalSystem.

There are a few options available for testing code with external dependencies. The first is to actually test against the real components; perhaps with modified connection strings to test instances. For example, you could run your tests against a test instance of the database. The second is to use a mocking framework to provide mock implementations for the methods you are using. For example, you could write a quick implementation of LibraryService.IsAsinValid to use only with your tests. I’ve been using Moles recently, but there are many good frameworks available. Finally, you can use a pattern called Dependency Injection to allow your service code to be passed references to external dependencies.

The rest of this post will cover how to use the IDomainServiceFactory interface to enable Dependency Injection. There’s plenty to be said about the other testing options I listed above, but I won’t do it here. A little research should be able to help you determine if and when either of the other options is right for you.

Factoring External Dependencies

Now that we’ve identified our external dependencies, we can change the design slightly to allow them to be pass in to the DomainService. Instead of using the concrete types, LibraryService and ApprovalSystem, we’ll replace them with interfaces.

  public interface ILibraryService
  {
    bool IsAsinValid(string asin);
  }

  public interface IApprovalSystem
  {
    void RequestApproval(string author, string title, DateTime publishDate);
    void RequestApproval(string asin);
  }

Next, we’ll update the DomianService to use these interfaces. More importantly, we’ll update the service to require these dependencies be provided to the constructor.

  public class BookClubDomainService :
    LinqToEntitiesDomainService<BookClubEntities>
  {
    private readonly ILibraryService _libraryService;
    private readonly IApprovalSystem _approvalSystem;

    public BookClubDomainService(
      ILibraryService libraryService, IApprovalSystem approvalSystem)
    {
      if (libraryService == null)
      {
        throw new ArgumentNullException("libraryService");
      }
      if (approvalSystem == null)
      {
        throw new ArgumentNullException("approvalSystem");
      }

      this._libraryService = libraryService;
      this._approvalSystem = approvalSystem;
    }

    // Test 1: Operation should return all books
    // Test 2: Operation should return books with categories
    // Test 3: Operation should return books ordered by BookID
    public IQueryable<Book> GetBooks()
    {
      return this.ObjectContext.Books.Include("Category").
               OrderBy(b => b.BookID);
    }

    // Test 1: Operation should insert book
    // Test 2: Operation should set the added date
    // Test 3: Operation should request approval for book with invalid ASINs
    // Test 4: Operation should request approval for book not yet published
    public void InsertBook(Book book)
    {
      if ((book.EntityState != EntityState.Detached))
      {
        this.ObjectContext.ObjectStateManager.
          ChangeObjectState(book, EntityState.Added);
      }
      else
      {
        this.ObjectContext.Books.AddObject(book);
      }

      book.AddedDate = DateTime.UtcNow;

      if (!this._libraryService.IsAsinValid(book.ASIN))
      {
        this._approvalSystem.
          RequestApproval(book.Author, book.Title, book.PublishDate);
      }
      else if (book.PublishDate > book.AddedDate)
      {
        this._approvalSystem.RequestApproval(book.ASIN);
      }
    }
  }

If you tried to run this service now, you’d see it failing with an error along the lines of “No default constructor exists for the type BookClubDomainService”. To fix this error, we’ll need to understand a little more about how DomainServices are instantiated.

IDomainServiceFactory

Each time a client calls into the DomainService endpoint, the RIA hosting layer uses the singleton DomainService.Factory to create a new instance of the requested DomainService type. The default IDomainServiceFactory implementation expects a DomainService type to provide a parameter-less constructor. Since we’ve changed the constructor above to require two parameters, we now have to create a factory type that can handle our DomainService.

Factories are pretty straightforward to write and only expose a pair of Create/Release methods.

  public class BookClubDomainServiceFactory : IDomainServiceFactory
  {
    public DomainService CreateDomainService(
      Type domainServiceType, DomainServiceContext context)
    {
      DomainService domainService;
      if (typeof(BookClubDomainService) == domainServiceType)
      {
        domainService = new BookClubDomainService(
          new LibraryService(), new ApprovalSystem());
      }
      else
      {
        domainService = (DomainService)
          Activator.CreateInstance(domainServiceType);
      }

      domainService.Initialize(context);
      return domainService;
    }

    public void ReleaseDomainService(DomainService domainService)
    {
      domainService.Dispose();
    }
  }

Now that we have a custom factory, we’ll have to make sure it gets used to instantiate our DomainService. The easiest way to do this is to add a Global.asax file to our web site and bootstrap the factory there.

  public class Global : System.Web.HttpApplication
  {
    protected void Application_Start(object sender, EventArgs e)
    {
      DomainService.Factory = new BookClubDomainServiceFactory();
    }
  }

Now we can run our service successfully again. The update we made to the DomainService will allow us to pass in test-specific implementations of the external dependencies. This in-turn improves the isolation and consistency of our tests. In parts two and three, I will show how to treat your data access layer as an external dependency and how to actually write the tests.

[A Note on Dependency Injection]

Often Dependency Injection is done in a more generic fashion using Injection frameworks. If you find yourself creating a big switch in IDomainServiceFactory.CreateDomainService for each DomainService type in your custom factory, you may find it more maintainable to use a framework. There are plenty of them out there, so it shouldn’t be too hard to find one that works for you.

[An Alternate Design]

Now that you’ve patiently waded through this entire post, it’s worth noting that a custom IDomainServiceFactory is not strictly required to make your DomainService testable. For instance, you could provide two constructors for each DomainService; the parameterized constructor for testing and a default constructor that chooses a default value for each dependency. There are benefits to the factory approach (like Dependency Injection), but I’ll leave it up to you to pick the one that fits best.

Unit Testing Series

WCF RIA Services in Windows Azure AppFabric June CTP

2011-06-24T14:06:19Z

If you’ve been using RIA in the cloud or are considering it, it is definitely worth your time to take a look at the Windows Azure AppFabric June CTP. The CTP is an early look at a platform that is positioned to simplify the development, deployment, and maintenance of applications in the cloud. We’ve made sure RIA works well in the AppFabric environment and that it’s just as easy to build a scalable application for the cloud as it is to build an on-premise web application.

Links

Since the CTP is large and encompasses a number of different technologies, I thought it’d be worth drawing your attention to RIA-specific links.

Here’s an overview of RIA in AppFabric Applications

Here’s an overview of the Silverlight Business Application Pattern for AppFabric

You can download the AppFabric Samples for the June CTP here

Also, when you download the CTP, make sure you install the AppFabricVsToolsCtp.

Take a Look

I thought about adding some snapshots to this post, but all the RIA stuff is just the same as you’re used to. The goal was to make it easy for you to pick up the CTP and play around with the bits. So take a look and send me some feedback. Let me know how it handles and the kinds of things you want to see. Thanks.

Writing a Custom CollectionViewLoader for the DomainCollectionView and MVVM

2011-05-13T17:05:30Z

The question I’ve been fielding most lately is how to write a custom CollectionViewLoader. Once you see it done, it’s a pretty simple task. Without an example it’s hard to know where to start. In a previous post, I discussed how the view, loader, and source related to each other. In this post, I’ll show how that translates to the code you write.

The Loader as part of your View Model

Out of the three parts of the DomainCollectionView (DCV) triad, the loader is the piece mostly closely aligned with your View Model. In fact, I wrote the default implementation (the DomainCollectionViewLoader) with callbacks so you could put all the code you cared about directly in your VM. That said, feel free to blur the lines between your VM and your CollectionViewLoader until you find the balance of functionality and reusability you feel comfortable with.

The CollectionViewLoader

A good place to start is to take a look at public surface area of the CollectionViewLoader type you’ll be extending.

  public abstract class CollectionViewLoader
  {
    public event EventHandler CanLoadChanged;
    public event AsyncCompletedEventHandler LoadCompleted;

    public abstract bool CanLoad { get; }

    public abstract void Load(object userState);
  }

It’s a simple abstract class with one method, one property, and two events. The Load method is responsible for asynchronously loading data into the source collection of the collection view. Since the Load method is asynchronous, it needs to raise a LoadCompleted event when it completes. The CanLoad property tells the DCV whether it can safely invoke the Load method. There are a number of CanXx properties in the ICollectionView interface, and changes to the CanLoad property will propagate to all of them. For example, since re-sorting the DCV will result in a Load call, CanSort will be set to false when CanLoad is false.

The Sample

I’ve also had a number of questions lately about how to use the DCV with the MVVM pattern I proposed in a recent post. This will be a two-birds-with-one-stone sample where I’ll show how to write a custom CollectionViewLoader that works with the MVVM service pattern. It’s worth noting this sample is a variant of the one I published with my original DCV post.

I’ll start with the custom loader code and work back through the rest of the sample.

  public class SampleCollectionViewLoader<TEntity>
    : CollectionViewLoader where TEntity : Entity
  {
    private Action<Action<ServiceLoadResult<TEntity>>, object> _load;
    private Action<object> _cancelLoad;
    private Action<ServiceLoadResult<TEntity>> _onLoadCompleted;

    private object _currentUserState;

    public SampleCollectionViewLoader(
        Action<Action<ServiceLoadResult<TEntity>>, object> load,
        Action<object> cancelLoad,
        Action<ServiceLoadResult<TEntity>> onLoadCompleted)
    {
      if (load == null)
      {
        throw new ArgumentNullException("load");
      }
      if (onLoadCompleted == null)
      {
        throw new ArgumentNullException("onLoadCompleted");
      }

      this._load = load;
      this._cancelLoad = cancelLoad;
      this._onLoadCompleted = onLoadCompleted;
    }

    public override bool CanLoad
    {
      get { return true; }
    }

    private object CurrentUserState
    {
      get
      {
        return this._currentUserState;
      }

      set
      {
        if (this._currentUserState != value)
        {
          if (this._cancelLoad != null)
          {
            this._cancelLoad(this._currentUserState);
          }
        }

        this._currentUserState = value;
      }
    }

    public override void Load(object userState)
    {
      if (!this.CanLoad)
      {
        throw new InvalidOperationException(
                    "Load cannot be called when CanLoad is false");
      }
      this.CurrentUserState = userState;
      this._load(this.OnLoadCompleted, userState);
    }

    private void OnLoadCompleted(ServiceLoadResult<TEntity> result)
    {
      this._onLoadCompleted(result);

      if (this.CurrentUserState == result.UserState)
      {
        this.CurrentUserState = null;
      }

      base.OnLoadCompleted(result);
    }
  }

This custom CollectionViewLoader in this sample is pretty straightforward and follows the pattern used in the DomainCollectionViewLoader to call back into the view model. It has three callbacks; one for loading, one for canceling, and one for load completion. As you can see, the signature of the callbacks differs from the ones in the DomainCollectionViewLoader. This is necessary to work with the service layer in a natural way which I’ll explain more in the next section.

There are a couple more things to note about this implementation. First, I haven’t done anything with the CanLoad property. In the sample I include a IsGridEnabled flag in the SampleViewModel that serves roughly the same purpose (and behaves a little nicer from a UI perspective when using the standard Silverlight DataGrid). Second, the bulk of the code that’s not calling into the view model is related to cancellation. I’ll talk a little more about that at the end.

The next part of the sample to look at is the service interface. It’s pretty simple and encapsulates loading sample entities.

  public interface ISampleService
  {
    EntityContainer EntityContainer { get; }

    void LoadSampleEntities(
      QueryBuilder<SampleEntity> query,
      Action<ServiceLoadResult<SampleEntity>> callback,
      object state);
  }

Next, we’ll take a look at the view model. It’s going to be the place where the SampleCollectionViewLoader, the SampleService, and all the callbacks are tied together.

  public SampleViewModel()
  {
    this._source = new EntityList<SampleEntity>(
      this._service.EntityContainer.GetEntitySet<SampleEntity>());

    this._loader = new SampleCollectionViewLoader<SampleEntity>(
      this.LoadSampleEntities,
      this.CancelLoadSampleEntities,
      this.OnLoadSampleEntitiesCompleted);

    this._view = new DomainCollectionView<SampleEntity>(
      this._loader,
      this._source);

    // Go back to the first page when the sorting changes
    INotifyCollectionChanged notifyingSortDescriptions = 
      this.CollectionView.SortDescriptions;
    notifyingSortDescriptions.CollectionChanged +=
      (sender, e) => this._view.MoveToFirstPage();

    using (this.CollectionView.DeferRefresh())
    {
      this._view.PageSize = 10;
      this._view.MoveToFirstPage();
    }
  }

The source is created using an EntitySet provided by the EntityContainer in the ISampleService. The loader now creates a SampleCollectionViewLoader and passes in three view model callbacks. We’ll take a look at two of those callbacks next.

  private void LoadSampleEntities(
    Action<ServiceLoadResult<SampleEntity>> onLoadCompleted,
    object userState)
  {
    this.IsGridEnabled = false;

    this._service.LoadSampleEntities(
      new QueryBuilder<SampleEntity>().SortAndPageBy(this._view),
      onLoadCompleted,
      userState);
  }

  private void OnLoadSampleEntitiesCompleted(
    ServiceLoadResult<SampleEntity> result)
  {
    this.IsGridEnabled = true;

    if (result.Error != null)
    {
      // TODO: handle errors
    }
    else if (!result.Cancelled)
    {
      this._source.Source = result.Entities;

      if (result.TotalEntityCount != -1)
      {
        this._view.SetTotalItemCount(result.TotalEntityCount);
      }
    }
  }

If you’ve followed my previous posts on the subject (linked prolifically above), these two implementations will look very familiar. The only significant difference is that the loader passes a completion callback and user state through to the LoadSampleEntities method for it to pass to the service layer. When the service load completes, it will tell the loader which will in-turn tell the view model.

A Note on Cancellation

Cancellation is a tricky subject on its own, but I’ll try to address how it fits into this pattern. Since a CollectionViewLoader is only dealing with one set of data, each subsequent load should cancel the previous one. In the sample for the MVVM pattern, I had cancellation in the service layer. It’s an approach that worked on the assumption you only invoke one current load per entity type. It’s pretty easy to see how this assumption fails to scale, though, so other approaches are necessary. If you find yourself using the same load method for multiple purposes, I’d recommend adding a cancel method to the service layer that looks like CancelLoadXx(object userState). You can then invoke this from the cancel callback you pass to the loader.

Summary

Like I mentioned at the beginning of this post, I expect you to write custom CollectionViewLoaders that support the kinds of things you want to do in your view model. Hopefully this post gives you a template to start from. Feel free to customize it however you see fit.

Here’s the source for the sample. It shows a little more detail on things fit together. Let me know what you think and if you have questions.

http://code.msdn.microsoft.com/Writing-a-Custom-e0769d37

Survey: How Do You Use the DomainService Wizard?

2011-05-05T15:27:20Z

I need to ask a favor of all my regular readers out there (*crickets*). I often hear stories along the lines of “I use the DomainService Wizard to generate my DomainService. Then I make tiny changes to the generated code or metadata and may move it or split it into separate files. Later, when I update my database, I re-run the DomainService Wizard to re-generate my DomainService and manually merge the newly generated service with the old one.”

So my question is this: “What problem are you solving?”

I think we can all admit any solution where one of the steps is “manually merge” is sub-optimal. This is something I want to fix. If you’ll oblige me, I’d love to hear what you’re doing and why you’re doing it (as a bonus, responding to this post makes it much more likely I’ll address your scenario).

Feel free to add a short comment with your thoughts or email me directly. Thanks.

MVVM Pattern for RIA Services

2011-04-29T16:06:06Z

At the Silverlight Firestarter ‘10, John Papa did a great talk on MVVM Patterns for Silverlight and WP7 that featured WCF RIA Services as the data layer. For that talk, I helped him streamline the service layer abstraction to correctly work with the RIA client. However, there were a number of great RIA features like querying and change tracking that weren’t surfacing in the view model layer. It was such a shame that I wanted to take a second pass over the pattern to see if I could make it better. I was able to sort out things a little better leading up to Mix ‘11 and the result is the new QueryBuilder type we shipped in the RIA Toolkit.

I’ve put together a reworked version of John’s BookShelf sample to highlight the changes.

The BookShelf Sample

The primary type we’re interested in here is the IBookDataService. Also interesting are the types that implement and consume it. Thankfully this is a small list composed of the interface, the design-time implementation, the actual implementation, and the view model. I’ll make changes to each and try explain the rationale in this post. Typically the deciding factor is whether a type can be returned by a mock or design-time implementation (and to a lesser extent, whether the design is awesome).

In addition, I wrote up some result types that bring a lot of the value of the RIA Operation types to the view model layer. I’ll cover those in a section at the end.

IBookDataService

Since the changes to the service interface drive the changes elsewhere, we should start by looking at the IBookDataService.

  public interface IBookDataService
  {
    EntityContainer EntityContainer { get; }

    void SubmitChanges(
           Action<ServiceSubmitChangesResult> callback,
           object state);

    void LoadBooksByCategory(
           int categoryId,
           QueryBuilder<Book> query,
           Action<ServiceLoadResult<Book>> callback,
           object state);
    void LoadBooksOfTheDay(
           Action<ServiceLoadResult<BookOfDay>> callback,
           object state);
    void LoadCategories(
           Action<ServiceLoadResult<Category>> callback,
           object state);
    void LoadCheckouts(
           Action<ServiceLoadResult<Checkout>> callback,
           object state);
  }

There are a few things worth noting. First, the EntityContainer is available as part of the interface. If you aren’t familiar with it, the EntityContainer is the type the DomainContext uses to store EntitySets, implement change tracking, and compose change sets. Luckily, the EntityContainer is designed such that it can live as easily in a mock implementation as the real one. Adding it to the service layer provides a lot of power while still enabling both separation and testability.

Second, all the callbacks pass a service result type. These types contain a distilled version of their RIA counterparts (LoadOperation, etc.) and I’ll cover them at the end.

Finally, the LoadBooksByCategory method takes both the categoryId and a QueryBuilder as arguments. This not only allows the service layer to filter the books by category, but it also allows the view model layer to put together custom queries that will be run on the server (sorting, paging, etc.).

DesignBookDataService

The design-time service implementation is simple and closely resembles the original version.

  public class DesignBookDataService : IBookDataService
  {
    private readonly EntityContainer _entityContainer =
      new BookClubContext.BookClubContextEntityContainer();

    public EntityContainer EntityContainer
    {
      get { return this._entityContainer; }
    }

    ...

    public void LoadBooksByCategory(
                  int categoryId,
                  QueryBuilder<Book> query,
                  Action<ServiceLoadResult<Book>> callback,
                  object state)
    {
      this.Load(query.ApplyTo(new DesignBooks()), callback, state);
    }

    ...

    private void Load<T>(
                   IEnumerable<T> entities,
                   Action<ServiceLoadResult<T>> callback,
                   object state)
                 where T : Entity
    {
      this.EntityContainer.LoadEntities(entities);
      callback(new ServiceLoadResult<T>(entities, state));
    }
  }

The EntityContainer is the same internal type as the one use in the BookClubContext, but could easily be mocked if the design-time service and generated proxies lived in different assemblies.

The LoadBooksByCategory method applies the query to a static data-set before invoking a generic Load method. The generic version makes sure the entities are contained in the EntityContainer and then asynchronously invokes the callback.

BookDataService

The actual service implementation is greatly simplified and is now much closer to the design-time version.

  public class BookDataService : IBookDataService
  {
    private readonly BookClubContext _context = new BookClubContext();

    ...

    public EntityContainer EntityContainer
    {
      get { return this._context.EntityContainer; }
    }

    ...

    public void LoadBooksByCategory(
                  int categoryId,
                  QueryBuilder<Book> query,
                  Action<ServiceLoadResult<Book>> callback,
                  object state)
    {
      this.Load(
        query.ApplyTo(this._context.GetBooksByCategoryQuery(categoryId)),
        lo =>
        {
          callback(this.CreateResult(lo, true));
        }, state);
    }

    ...

    private void Load<T>(
                   EntityQuery<T> query,
                   Action<LoadOperation<T>> callback,
                   object state)
                 where T : Entity
    {
      ...
      this._context.Load(query, lo =>
        {
          ...
          callback(lo);
        }, state);
    }
    private ServiceLoadResult<T> CreateResult<T>(
                                   LoadOperation<T> op,
                                   bool returnEditableCollection = false)
                                 where T : Entity
    {
      if (op.HasError)
      {
        op.MarkErrorAsHandled();
      }
      return new ServiceLoadResult<T>(
        returnEditableCollection ?
          new EntityList<T>(
            this.EntityContainer.GetEntitySet<T>(),
            op.Entities) :
          op.Entities,
        op.TotalEntityCount,
        op.ValidationErrors,
        op.Error,
        op.IsCanceled,
        op.UserState);
    }
  }

Again we can see the LoadBooksByCategory method applying the query; this time to an EntityQuery. It also creates a callback that it can pass through to the DomainContext.Load method.

It’s worth noting the CreateResult method has the option to return an editable collection or a read-only one. When we take a look at the view model, you’ll be able to see it working against both.

BookViewModel

The view model has changed a number of things to consume the new interface, but it’s all still pretty straightforward.

  public class BookViewModel : ViewModel
  {
    private const int _pageSize = 10;

    private int _pageIndex;

    protected IPageConductor PageConductor { get; set; }
    protected IBookDataService BookDataService { get; set; }

    ... 

    public BookViewModel(
      IPageConductor pageConductor,
      IBookDataService bookDataService)
    {
      PageConductor = pageConductor;
      BookDataService = bookDataService;
      BookDataService.EntityContainer.PropertyChanged +=
        BookDataService_PropertyChanged;

      RegisterCommands();
      LoadData();
    }

    private void BookDataService_PropertyChanged(
                   object sender, PropertyChangedEventArgs e)
    {
      if (e.PropertyName == "HasChanges")
      {
        HasChanges = BookDataService.EntityContainer.HasChanges;
        SaveBooksCommand.RaiseCanExecuteChanged();
      }
    }

    ...

    public void LoadBooksByCategory()
    {
      _pageIndex = 0;
      Books = null;
      if (SelectedCategory != null)
      {
        BookDataService.LoadBooksByCategory(
          SelectedCategory.CategoryID,
          new QueryBuilder<Book>().Take(_pageSize),
          LoadBooksCallback,
          null);
      }
    }

    private void OnLoadMoreBooksByCategory()
    {
      if (SelectedCategory != null)
      {
        _pageIndex++;
        BookDataService.LoadBooksByCategory(
          SelectedCategory.CategoryID,
          new QueryBuilder<Book>()
                .Skip(_pageIndex * _pageSize).Take(_pageSize),
          LoadBooksCallback,
          null);
      }
    }

    public void LoadBooksByTitle()
    {
      _pageIndex = 0;
      Books = null;
      if (SelectedCategory != null)
      {
        BookDataService.LoadBooksByCategory(
          SelectedCategory.CategoryID,
          new QueryBuilder<Book>()
                .Where(b => b.Title.Contains(TitleFilter)),
          LoadBooksCallback,
          null);
      }
    }

    private void LoadBooksCallback(ServiceLoadResult<Book> result)
    {
      if (result.Error != null)
      {
        // handle error
      }
      else if (!result.Cancelled)
      {
        if (Books == null)
        {
          Books = result.Entities as ICollection<Book>;
        }
        else
        {
          foreach (var book in result.Entities)
          {
            Books.Add(book);
          }
        }

        SelectedBook = Books.FirstOrDefault();
      }
    }

    private ICollection<Book> _books;
    public ICollection<Book> Books
    {
      get { return _books; }
      set
      {
        _books = value;
        RaisePropertyChanged("Books");
      }
    }

    ...
  }

The first place to highlight is in the constructor where the view model subscribes to property change events on the EntityContainer. This allows the view model to listen directly for changes made to any of the entities it is working against.

The second point of interest is the three, similarly-implemented load methods. The significant difference between each implementation is the query it composes to pass to the IBookDataService. In all three cases, the composed query will be run on the server.

Finally, the LoadBooksCallback casts result.Entities to an ICollection<Book>. This is because Books is a collection that supports the adding and removing of entities. In this case, the collection is simply aggregating the results of multiple queries, but the same pattern could be used for the creation of new entities. The reason this pattern works is because the BookDataService is returning an EntityList from CreateResult (above), and EntityList knows how to correctly handle the addition and removal of entities.

Service Result Types

I added three result types to the sample (to the Ria.Common project), ServiceInvokeResult, ServiceLoadResult, and ServiceSubmitChangesResult. While the base operation types have some great features, they aren’t convenient to use in mock or design-time implementations. In addition, there is a lot of useful information in these types that is important to return from the service layer. Each of the result types has properties that closely parallel their operation types. For instance, the ServiceLoadResult has properties for the Error and Cancelled states as well as the enumerable Entities. As can be seen in the LoadBooksCallback above, the pattern for consuming the result type is very similar to the standard RIA pattern; check for errors, check for cancelation, and then process the entities.

QueryBuilder and the DomainCollectionView

Though it isn’t apparent in this sample, the QueryBuilder also acts as a bridge between the DomainCollectionView (read about the DomainCollectionView) and the service layer. Each of the query extensions provided for the DCV work against the QueryBuilder as well. For instance, SortAndPageBy could be applied to the query in the view model before passing the QueryBuilder to the service layer.

Summary

I covered a lot in this post and I wouldn’t be surprised if there are still questions to be answered. It’s not my desire to present a canonical MVVM pattern with this post, but the design here is well-worn and a good place to start. Hopefully types, ideas, and patterns in this post prove useful to you. Please let me know what think and if you have any questions.

[Interesting Variations]

Since writing this, there have been a few intrepid developers who’ve written variations on the pattern worth mentioning.

Remco combined the pattern with my guidance on using Tasks (from the VS Async CTP) to create a Task Based MVVM Sample.
Colin riffed in a couple directions first combining the pattern with MEF and then splitting it into a number of class libraries.

DomainCollectionView Updates for Mix ‘11

2011-04-15T15:30:12Z

To correspond to the new RIA Services build we’ve released at Mix, I’ve made some updates to the DomainCollectionView. I updated select API, fixed a few bugs, and updated the sample as well. If you’re not familiar with the DCV, here’s my original post introducing it. For the sake of brevity in this post, I’ll assume you’ve read it.

Breaking Changes

There are a few breaking changes to the API. Most notably, SortPageAndCount has been renamed. It’s a breaking change, but a simple find-replace should set things right again.

SortAndPageBy replaces SortPageAndCount
- SortAndPageBy calls SortBy and PageBy respectively
SortBy replaces Sort
- SortBy applies OrderBy and ThenBy clauses to the query
PageBy replaces Page
- PageBy applies Skip and Take clauses to the query and conditionally requests the TotalEntityCount
(All the other query extensions have been removed)

Bug Fixes

There were a few bug fixes that went in to improve compatibility with third-party controls. I’ve tested the DCV against four suites of controls now, and it works well with all of them. As always, let me know when you find issues.

Sample

A common question in response to the first post was how to implement filtering. It turns out to be pretty easy, so I wanted to make it obvious with some updates to my sample.

I’ve updated the UI to include a search field.

The search button now invokes the search command which calls into the OnSearch method in my SampleViewModel.

  private void OnSearch()
  {
    // This makes sure we refresh even if we're already on the first page
    using (this._view.DeferRefresh())
    {
      // This will lead us to re-query for the total count
      this._view.SetTotalItemCount(-1);
      this._view.MoveToFirstPage();
    }
  }

The OnSearch method resets the total item count and refreshes the view; leading us back into our load callback.

  private LoadOperation<SampleEntity> LoadSampleEntities()
  {
    this.CanLoad = false;

    EntityQuery<SampleEntity> query = this._context.GetAllEntitiesQuery();
    if (!string.IsNullOrWhiteSpace(this.SearchText))
    {
      query = query.Where(e => e.String.Contains(this.SearchText));
    }

    return this._context.Load(query.SortAndPageBy(this._view));
  }

To make sure the filter gets applied on the server, we conditionally add a Where clause to our query based on the content of the SearchText.

That covers the new additions to the DomainCollectionView. Once again we’ve put together a small sample running with server-side filtering, sorting, grouping, and paging. Here’re the sample bits. Let me know if you have any questions.

http://code.msdn.microsoft.com/Server-Side-Filtering-737becda

Using RIA Services with ComboBoxes and Enums

2011-01-06T21:29:09Z

The other day someone asked me how to get a ComboBox working with enums and validation. It turned out to be more tricky than I had anticipated (there’s a common theme here…) so I figured I’d put together a quick post on it.

Stumbling Points

This section describes two specific traps I fell into. It’s not necessarily important for you to understand the details, but I’ll include them just in case you’re interested. Feel free to skip straight to the solution.

My first error was related to sharing enums in RIA. Due to the way enums appear in assembly metadata, the RIA code generator can’t determine whether they exist on the client or not. If you put an enum in a .shared.cs or .shared.vb file, it will quickly result in a compile error. The solution to this issue is simple. Instead of sharing the enum between tiers, just define it on your server and let codegen take care of the rest.

The second error I ran into was using client-side projection properties. In the past I’ve preferred these to using an IValueConverter in my bindings, but this investigation (finally) helped me to realize this approach has adverse effects on RIA validation. When the property being validated is named something other than the property being set (for example, the MyString property would write through to the MyEnum property where validation would occur) the visual control state will not be updated to reflect the error (no fancy red adornment).

The Solution

I eventually ended up using an IValueConverter-based solution. I put a little extra work into it to make it DisplayAttribute-aware since metadata is a commonly-used RIA feature. I wrote a utility to encapsulate most of this, but I’ll go over that piece at the end once you’ve got a grip on how it all fits together. (Similar variants of this solution are available in a number of places, but I wanted to fill in some of the corners that often get ignored)

I applied these changes to the sample I used in this post (http://blogs.msdn.com/b/kylemc/archive/2010/11/12/silverlight-tv-52-ria-services-q-a.aspx) if you want a place to try it out. These steps should work in any scenario, though.

To create the look above, I defined a simple enum with DisplayAttributes on each of the values.

  public enum MyEnum
  {
    [Display(Name = "(please pick a value)")]
    None = 0,
    [Display(Name = "Value 1")]
    Value1 = 1,
    [Display(Name = "Value 2")]
    Value2 = 2,
    [Display(Name = "Value 3")]
    Value3 = 3,
  }

Then I added a property to my entity that used custom validation to ensure a non-zero value is selected.

  [CustomValidation(typeof(Validation), "ValidateMyEnum")]
  [DataMember]
  public MyEnum MyEnum { get; set; }

(My validation is in a shared file in the web project, Validation.shared.cs)

  public static class Validation
  {
    public static ValidationResult ValidateMyEnum(
      MyEnum myEnum, ValidationContext context)
    {
      if (myEnum == MyEnum.None)
      {
        return new ValidationResult(
          "You must pick a value.", new[] { context.MemberName });
      }
      return ValidationResult.Success;
    }
  }

My next step was to define the ComboBox on the client.

  <ComboBox ItemsSource="{StaticResource myEnumNames}"
            SelectedItem="{Binding Path=MyEnum,
                                   Mode=TwoWay,
                                   Converter={StaticResource enumToString}}"
  />

The SelectedItem binding references a converter I instantiate in my page resources.

  <app:EnumToStringValueConverter x:Key="enumToString" />

The code for the converter is simple and leverages the EnumUtility I’ll describe a little later. It is also generic so a single instance can be shared between multiple types of enums.

  public class EnumToStringValueConverter : IValueConverter
  {
    public object Convert(object value, Type targetType,
      object parameter, CultureInfo culture)
    {
      return EnumUtility.GetName(value.GetType(), value);
    }

    public object ConvertBack(object value, Type targetType,
      object parameter, CultureInfo culture)
    {
      return EnumUtility.GetValue(targetType, value.ToString());
    }
  }

The ItemsSource in the ComboBox above uses a static resource I add in my page constructor before parsing the xaml (in InitializeComponent). I’ve used the EnumUtility again to get the names for my enum.

  this.Resources.Add("myEnumNames", EnumUtility.GetNames(typeof(MyEnum)));
  InitializeComponent();

With all the pieces in place (an enum, a property to bind to, a converter, a list of names, and a ComboBox), I now have a ComboBox bound to an enum and validating input.

An Enum Utility

I wrote a utility class to handle most of the heavy lifting here. For each enum type, it iterates through all the values and figures out the names they should be mapped to. The GetName and GetValue methods map back and forth between the two. Here’s the source in case you’re interested.

  public static class EnumUtility
  {
    private static readonly
      IDictionary<Type, IEnumerable<string>> names =
        new Dictionary<Type, IEnumerable<string>>();
    private static readonly
      IDictionary<Type, IEnumerable<object>> values =
        new Dictionary<Type, IEnumerable<object>>();
    private static readonly
      IDictionary<Type, IDictionary<string, object>> namesToValues =
        new Dictionary<Type, IDictionary<string, object>>();
    private static readonly
      IDictionary<Type, IDictionary<object, string>> valuesToNames =
        new Dictionary<Type, IDictionary<object, string>>();

    public static void Initialize(Type type)
    {
      Initialize(type, GetDisplayAttributeName);
    }

    public static void Initialize(
      Type type, Func<FieldInfo, string> getName)
    {
      if (type == null)
      {
        throw new ArgumentNullException("type");
      }

      if (!type.IsEnum)
      {
        throw new ArgumentException("Type must be an enum.", "type");
      }

      if (getName == null)
      {
        throw new ArgumentNullException("getName");
      }

      if (names.ContainsKey(type))
      {
        return;
      }
        
      List<string> tempNames = new List<string>();
      List<object> tempValues = new List<object>();
      Dictionary<string, object> tempNamesToValues =
        new Dictionary<string, object>();
      Dictionary<object, string> tempValuesToNames =
        new Dictionary<object, string>();

      foreach (FieldInfo fi in
        type.GetFields(BindingFlags.Public | BindingFlags.Static))
      {
        string name = getName(fi);
        object value = fi.GetValue(null);

        tempNames.Add(name);
        tempValues.Add(value);
        tempNamesToValues[name] = value;
        tempValuesToNames[value] = name;
      }

      names[type] = tempNames;
      values[type] = tempValues;
      namesToValues[type] = tempNamesToValues;
      valuesToNames[type] = tempValuesToNames;
    }

    private static string GetDisplayAttributeName(FieldInfo fi)
    {
      DisplayAttribute displayAttribute = 
       (DisplayAttribute)fi.GetCustomAttributes(
         typeof(DisplayAttribute), false).FirstOrDefault();

      return (displayAttribute == null) ? fi.Name : displayAttribute.Name;
    }

    public static IEnumerable<string> GetNames(Type type)
    {
      Initialize(type);
      return names[type];
    }

    public static IEnumerable<object> GetValues(Type type)
    {
      Initialize(type);
      return values[type];
    }

    public static string GetName(Type type, object value)
    {
      Initialize(type);
      return valuesToNames[type][value];
    }

    public static object GetValue(Type type, string name)
    {
      Initialize(type);
      return namesToValues[type][name];
    }
  }

Collection Binding Options in WCF RIA Services SP1

2010-12-02T17:05:43Z

One of the most common tasks when developing a RIA Services application binding to a collection of data. There are some declarative options that include binding directly to your DomainContext or DomainDataSource. These options are great for spinning up applications quickly, but don’t translate well to view model patterns. For that reason, I thought it’d be worth taking a moment to go through the options that make sense in an MVVM context.

Bind to an EntitySet

As of SP1, we improved binding support for EntitySets. EntitySets are aggregating, un-ordered collections. That means every time an entity is loaded by your DomainContext it will be added to its corresponding EntitySet. Binding to an EntitySet will give you a great view of every entity of a specific type your DomainContext knows about. Adding to or removing from an EntitySet will result in calls to the insert and delete operations being invoked when you submit changes to your DomainService.

Making an EntitySet available in your view model would look like this.

  public EntitySet<SampleEntity> EntitySet
  {
    get { return this.Context.SampleEntities; }
  }

Bind to an EntityCollection

In SP1, we also improved binding support for EntityCollections. EntityCollections are collections of entities associated with a specific Entity. In a manner similar to the EntitySet, an EntityCollection will be updated as new entities are loaded into your DomainContext. Each will be added to the EntityCollection of the Entity it is associated with. Adding and removing from an EntityCollection will only update the association. Most of the time, this results in an update operation being invoked when you submit changes.

Since EntityCollections are tied to specified Entities, having a property on your view model seems like an uncommon case. Nevertheless, making an EntityCollection available in your view model would look like this.

  public EntityCollection<SampleEntity> EntityCollection
  {
    get { return this.CurrentEntity.AssociatedEntities; }
  }

Bind to an EntityList

EntityList is a type new to SP1 and can be found in Microsoft.Windows.Data.DomainServices in the Toolkit. An EntityList is an observable collection backed by an EntitySet. The Source property on the EntityList defines the entities it contains, and it will not update as new entities are loaded into your DomainContext. It will update if entities it contains are deleted from the EntitySet or when entities are added or removed from its Source collection. Adding to an EntityList will behave in one of two ways. If the entity already exists in the backing EntitySet, then it is just added to the list. If it does not exist, then it will be added to the EntitySet as well. Removing from the EntityList will always remove the entity from the backing EntitySet. Binding to an EntityList is a great option when you only want to see a subset of the entities your DomainContext knows about.

Making an EntityList available in your view model would look like this.

  private EntityList<SampleEntity> _entityList;
  public EntityList<SampleEntity> EntityList
  {
    get
    {
      if (this._entityList == null)
      {
        this._entityList = new EntityList<SampleEntity>(
          this.Context.SampleEntities);
      }
      return this._entityList;
    }
  }

  private void LoadSampleEntities()
  {
    this.EntityList.Source =
      this.Context.Load(this.Context.GetAllEntitiesQuery()).Entities;
  }

Bind to an ICollectionView

In case you’re not familiar with the ICollectionView interface, it’s used by a number of components (DataGrid, DataForm, etc.) as a view over a source collection. For example, when you bind DataGrid.ItemsSource to a collection, it will create a collection view behind the scenes to interact with. Instead of just having the control instantiate a view behind the scenes, you have the option of making the ICollectionView available for binding directly from your view model.

It may not be readily apparent why you’d do this, but as you did into the interface, you’ll noticed it has a number of properties for defining how the view presents the source collection. You can control the sorting, grouping, and filtering as well as which item is selected; all from the ICollectionView.

In Silverlight, most collection view implementations are internal. Fortunately, there’s an easy way of letting the framework instantiate the correct view for the collection that uses the CollectionViewSource.

  private static ICollectionView CreateView(IEnumerable source)
  {
    CollectionViewSource cvs = new CollectionViewSource();
    cvs.Source = source;
    return cvs.View;
  }

Making an ICollectionView available in your view model would look like this.

  private ICollectionView _collectionView;
  public ICollectionView CollectionView
  {
    get
    {
      if (this._collectionView == null)
      {
        this._collectionView = CreateView(this.Context.SampleEntities);
      }
      return this._collectionView;
    }
  }

The downside of using this approach is that all the existing collection view implementations only operate over the in-memory collection. That means you have to pull all the data to Silverlight before you apply sorting or filtering.

Bind to a DomainCollectionView

To address the limitations of existing ICollectionView implementations we’ve added the DomainCollectionView in SP1 in Microsoft.Windows.Data.DomainServices in the Toolkit. It is designed to allow for asynchronous sorting, grouping, and paging, and works with all the controls that use the collection view interfaces. This enables you to page over data on your server using the core data controls.

The setup for a DomainCollectionView is slightly more complicated than some of these other options. This is because it requires load callbacks as well as a source collection. These callbacks can be implemented just like any other load operation in your view model.

  private LoadOperation<SampleEntity> LoadSampleEntities()
  {
    return this.Context.Load(
      this.Context.GetAllEntitiesQuery().SortPageAndCount(
        this.DomainCollectionView));
  }

  private void OnLoadSampleEntitiesCompleted(LoadOperation<SampleEntity> op)
  {
    if (op.HasError)
    {
      // TODO: handle errors
      op.MarkErrorAsHandled();
    }
    else if (!op.IsCanceled)
    {
      this.EntityList.Source = op.Entities;

      if (op.TotalEntityCount != -1)
      {
        this.DomainCollectionView.SetTotalItemCount(op.TotalEntityCount);
      }
    }
  }

With callbacks defined, making a DomainCollectionView available in your view model would look like this.

  private DomainCollectionView<SampleEntity> _domainCollectionView;
  public DomainCollectionView<SampleEntity> DomainCollectionView
  {
    get
    {
      if (this._domainCollectionView == null)
      {
        this._domainCollectionView =
          new DomainCollectionView<SampleEntity>(
            new DomainCollectionViewLoader<SampleEntity>(
              this.LoadSampleEntities,
              this.OnLoadSampleEntitiesCompleted),
            this.EntityList);
      }
      return this._domainCollectionView;
    }
  }

This is just enough to get you started with the DomainCollectionView, but it leaves out most of the details. In this next post, I go much more in-depth and explain the design and core API.

http://blogs.msdn.com/b/kylemc/archive/2010/12/02/introducing-an-mvvm-friendly-domaindatasource-the-domaincollectionview.aspx

Are there other options?

There are always other options, but I’m not sure I’d recommend using them. One common alternative would be to make the property types of these collections their respective interfaces (for instance IEnumerable or ICollectionView). This can reduce coupling and give you more flexibility. Also, since most Silverlight controls that bind to collections are just looking for interfaces, the impact is negligible.

If you have other suggestions, I’d love to hear them. Hope this overview helps.

Introducing An MVVM-Friendly DomainDataSource: The DomainCollectionView

2010-12-02T17:03:55Z

[This sample references out-of-date API. This newer post discusses the updates made for the V1 SP2 Preview and shows how to implement filtering.]

There’ve been plenty of talk about an MVVM-friendly DomainDataSource. I’m pretty sure it means completely different things to different people. I even took a stab at defining it a while back. What we’ve included in the Microsoft.Windows.Data.DomainServices assembly in the Toolkit closely follows that outline.

Since this is the first look at this component, I feel compelled to tell you what we’ve provided is more like an engine than a car. There’s a lot of power and flexibility in the DomainCollectionView design, but there are still a lot of ways to misuse it. We haven’t spent nearly as much time nailing down the use cases as we did on the DomainDataSource (for good or for bad).

Without further introduction, let’s dig in.

What is the DomainCollectionView?

The DomainCollectionView (herein referred to as the DCV) is a collection view implementation. The generic version of the class implements all the following interfaces. Most controls are designed to recognize and work against these interfaces.

ICollectionView
IEditableCollectionView
IPagedCollectionView
IEnumerable
IEnumerable<T>
INotifyPropertyChanged
INotifyCollectionChanged

For fear of pushing you to the brink of insanity, I’ll forego listing the full API. Instead, I’ll just say there are a lot of properties and methods for you to get acquainted with. Here’s a list of the ones you’ll commonly find yourself using.

CurrentItem, CurrentPosition, and MoveCurrentToXx: This is treated as the selected item in most list controls
GroupDescriptions: This collection defines the way items are grouped and also affects server-side sorting
PageIndex, MoveToXxPage: Calling MoveToPage will prompt the view to load the page at the specified index
PageSize: This defines the number of items to load on each page
Refresh, DeferRefresh: Calling Refresh will prompt the view to load using the current view settings
SortDescriptions: This collection defines the way items are sorted and affects server-side sorting
SourceCollection: This is the collection that backs the view and only items in the collection will appear in the view
TotalItemCount, SetTotalItemCount: This is used to calculate the total number of pages

How Do I Use a DomainCollectionView?

The DCV is designed using the following triad.

In the design, the View component is the DCV. It’s primary functions are to funnel interface calls to the Loader and to respond to changes in the Loader and Source components.

The Loader component is the CollectionViewLoader. It is responsible for handling an asynchronous Load call and raising the LoadCompleted event upon completion. The DomainCollectionViewLoader is the default implementation and can be created with two callbacks allowing you to handle loading and load completion.

The Source component can be any collection that implements IEnumerable. However, observable collections tend to provide the best results. When the Loader gets data, it should update the source and the source should notify the view. EntityList works well as the source, especially in paging scenarios.

Your responsibilities fall mostly along the bottom of the triangle. When the view is refreshed (by a you or a control), it will ask you to load the appropriate data. This usually breaks down into the following steps.

Create an EntityQuery and apply the view state to the query. There are a number of EntityQuery extension methods, including Sort and Page, to make this easy on you.
Load the query.
In the completion callback, update the source collection with the new data. You may need to update the view as well if you queried for the TotalEntityCount (used in paging).

Let’s See Some Code

At this point, it will probably be easiest to see the pieces working together in code. This sample shows a read-only DataGrid where sorting and paging are both being done on the server. Here’s the DomainService I’ll be working with. The only thing to note here is I had to override Count to support paging since I’m deriving from the base DomainService.

  [EnableClientAccess()]
  public class SampleDomainService : DomainService
  {
    // Overridden to support paging over POCO entities.
    // If you're extending a derived DomainService
    // implementation this is already done for you.
    protected override int Count<T>(IQueryable<T> query)
    {
      return query.Count();
    }

    public IQueryable<SampleEntity> GetAllEntities() {…}
  }

On the client, I’m using a stripped-down version of the MVVM pattern for simplicity. The view isn’t terribly interesting, but I’ll start there anyway. Both the DataGrid and the DataPager are bound to the view model.

  <UserControl ...>

    <UserControl.DataContext>
        <vm:SampleViewModel />
    </UserControl.DataContext>
    
    ...

    
    <Grid ...>
      <Border ...>
        <Grid>
          ...
          <sdk:DataGrid Name="dataGrid1" Grid.Row="0"
                        ItemsSource="{Binding CollectionView}"
                        IsEnabled="{Binding IsGridEnabled}"
                        IsReadOnly="True"/>
          <sdk:DataPager Name="dataPager1" Grid.Row="1"
                         Source="{Binding CollectionView}"
                        IsEnabled="{Binding IsGridEnabled}"/>
        </Grid>
      </Border>
    </Grid>
  </UserControl>

Finally, we’ll get to the interesting piece, the view model. The two properties the view is bound to, CollectionView and IsGridEnabled, are the least interesting part so I’ll skip right past those to the constructor. This is where all the relationships get set up.

  public SampleViewModel()
  {
    this._source = new EntityList<SampleEntity>(
      this._context.SampleEntities);

    this._loader = new DomainCollectionViewLoader<SampleEntity>(
      this.LoadSampleEntities,
      this.OnLoadSampleEntitiesCompleted);

    this._view = new DomainCollectionView<SampleEntity>(
      this._loader,
      this._source);

    // Swap out the loader for design-time scenarios
    if (DesignerProperties.IsInDesignTool)
    {
      DesignTimeLoader loader = new DesignTimeLoader();
      this._view =
        new DomainCollectionView<SampleEntity>(loader, loader.Source);
    }

    // Go back to the first page when the sorting changes
    INotifyCollectionChanged notifyingSortDescriptions =
      (INotifyCollectionChanged)this.CollectionView.SortDescriptions;
    notifyingSortDescriptions.CollectionChanged +=
      (sender, e) => this._view.MoveToFirstPage();

    using (this.CollectionView.DeferRefresh())
    {
      this._view.PageSize = 10;
      this._view.MoveToFirstPage();
    }
  }

You can start to see things come together in the first couple of lines. The source is initialized with its backing EntitySet, the loader is initialized with a couple of callbacks, and the view is initialized with references to the first two.

The second things to notice is the block that adds design-time data. I’ve created a custom loader that returns a few sample entities and, at design time, construct a view using it instead. Not to get too sidetracked, but this snippet shows how easy it is to create a design-time loader.

  private class DesignTimeLoader : CollectionViewLoader
  {
    private static readonly IEnumerable<SampleEntity> source = new[] {…}

    public IEnumerable<SampleEntity> Source
    {
      get { return DesignTimeLoader.source; }
    }

    public override bool CanLoad { get { return true; } }
    public override void Load(object userState)
    {
      this.OnLoadCompleted(
        new AsyncCompletedEventArgs(null, false, userState));
    }
  }

Also, it’s worth noting there are plenty of other approaches to obtain sample data. I chose this one to highlight the simplicity of writing a custom loader and because it only required a few lines of code.

Finally, there are two more things to look at near the end of the constructor. First, I’ve added an event handler to the SortDescriptions collection. Now, every time the collection is updated with a new SortDescription, I’ll make sure the table moves back to the first page. This isn’t a necessary addition, but I liked the behavior a little bit better. Once everything is set up, I make a couple updates to the view in a DeferRefresh block. Any time you’re updating more than one view property and then reloading, it’s good practice to wrap it with a DeferRefresh. This tells the view to forego all recalculations until you’ve finished your update. Upon exiting the using block, the Refresh method will be invoked to update the view.

The next piece we’ll look at are the two callbacks I passed into the constructor of the DomainCollectionViewLoader. As far as RIA data loading goes, they’re both pretty standard.

  private LoadOperation<SampleEntity> LoadSampleEntities()
  {
    this.IsGridEnabled = false;

    return this._context.Load(
      this._context.GetAllEntitiesQuery().SortPageAndCount(this._view));
  }

  private void OnLoadSampleEntitiesCompleted(LoadOperation<SampleEntity> op)
  {
    this.IsGridEnabled = true;

    if (op.HasError)
    {
      // TODO: handle errors
      op.MarkErrorAsHandled();
    }
    else if (!op.IsCanceled)
    {
      this._source.Source = op.Entities;

      if (op.TotalEntityCount != -1)
      {
        this._view.SetTotalItemCount(op.TotalEntityCount);
      }
    }
  }

In the LoadSampleEntities callback, the most interesting part is the SortPageAndCount method. There are a number of EntityQuery extensions included in the CollectionViewExtensions class (Sort, Page, etc.) that understand how to apply the state of the view to the query. For instance, SortPageAndCount orders according to the sort and group descriptions, skip/takes using the page index and count, and requests the total number of items if that has not already been determined.

The OnLoadSampleEntitiesCompleted is also pretty simple. In the successful load block, the source is updated with the entities that were just loaded. Also, if the TotalEntityCount was requested, it is used to update the view’s TotalItemCount (which is used by the DataPager to determine the total number of pages). Enabling and disabling the grid is not a required step, but I liked how it looked.

Those are the significant bits of the sample. With a little setup and a couple callbacks, the DCV makes server-side paging simple and obtainable. If you’re interested in seeing it run, here’s a link to the source.

Cool, I Want More

The DomainCollectionView in Microsoft.Windows.Data.DomainServices in the Toolkit supports the view functions of sorting, grouping, and paging. In addition, you can apply server-side filtering as part of your load callback (using a .Where clause). These four pieces will be the core of nearly every query you put together on the client.

Even with all that, there are a number of features that existed in the DomainDataSource that could be pulled into the DCV. I included an extensive list of features in this post. Let me know what’s missing and what you’d like added the most.

As I mentioned earlier, this stuff is powerful and flexible to allows you to do cool stuff, but doesn’t work terribly hard to prevent you from doing things wrong. I’ve tried to provide some guidance with this post and the sample to keep things running smooth, but I’m sure you’ll take this in directions I haven’t anticipated. If you run into bugs or have questions about the best way to do things, send them my way (Email Kyle).

Windows Azure Table Storage LINQ Support

2010-11-22T21:18:24Z

Windows Azure Table storage has minimal support for LINQ queries. They support a few key operations, but a majority of the operators are unsupported. For RIA developers used to Entity Framework development, this is a significant difference. I wanted to put together this short post to draw your attention to this link.

When you use an unsupported operator, your application will fail at runtime. Typically the error is something along these lines.

An error occurred while processing this request.
at System.Data.Services.Client.DataServiceRequest.Execute[TElement](DataServiceContext context, QueryComponents queryComponents)
at System.Data.Services.Client.DataServiceQuery`1.Execute()
at System.Data.Services.Client.DataServiceQuery`1.GetEnumerator()
at SampleCloudApplication.Web.MyDomainService.GetMyParentEntitiesWithChildren()
at …

with an InnerException that looks like this.

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<error xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
<code>NotImplemented</code>
<message xml:lang="en-US">The requested operation is not implemented on the specified resource.</message>
</error>

To solve this problem, you will need to bring the data to the mid-tier (where your DomainService is running) using the .ToArray() method. For example, “return this.EntityContext.MyEntities.OrderBy(e => e.MyProperty)” will fail but “return this.EntityContext.MyEntities.ToArray().OrderBy(e => e.MyProperty)” will succeed.

The lack of support is an issue on the mid-tier, but has very little effect on the client. The base class, TableDomainService, does a lot of work processing the query to correctly handle most things sent from the client. The one caveat to this is some .Where filters are too complex to be processed. For example, most string operations like Contains can’t be used and string equality is case sensitive (so be sure to set FilterDescriptor.IsCaseSensitive to true when using DomainDataSource filters). Just like the other unsupported operators, you can still implement this on the mid-tier using .ToArray() before performing the complex .Where query.

Windows Azure Table PartitionKey Options for TableDomainServices

2010-11-19T16:48:36Z

There are three primary strategies when it comes to partitioning entities across Windows Azure Table Storage. You can:

Put everything in the same partition
Put everything in different partitions
Put things in two or more specific partitions

A full discussion of these options can be found in the Table Storage whitepaper, but I’ll take some time in the post to show how each strategy can be implemented in your TableDomainService. Each option hinges around the PartitionKey value in your TableDomainService and each of your entities.

The Single-PartitionKey Strategy

Using a single partition offers some attractive features like optimized querying and transactional updating. Since these fall most in line with existing domain service patterns, we chose to make this the default option in the TableDomainService.

By default, TableDomainService.PartitionKey returns the name of your domain service. This key is passed through to the EntityContext which makes sure to put all your entities in the same partition. It also knows enough to only search for your entities in that partition by optimizing it’s query.

In all three options, an entity’s PartitionKey will not be set if you specify it before adding the entity to the EntityContext. For this reason, it’s usually not a good idea to set the entity’s partition key explicitly when using this strategy.

The Unique-PartitionKey Strategy

Windows Azure will place entities with unique PartitionKeys in separate partitions. Using this strategy will give you the maximum amount of scalability.

To operate in this strategy, override TableDomainService.PartitionKey and return null. This tells both your domain service and the EntityContext they can’t assume a single key.

The Specific-PartitionKey Strategy

The final option allows you to balance the behaviors of the first two options in the way that best suits your application. You can improve scalability over using a single key while preserving transactional semantics over entities in the same partition.

For this strategy, you’ll again need to override TableDomainService.PartitionKey and return null. This time, however, you’ll also need to set every entity’s PartitionKey explicitly. At this point, partitioning is fully under your control.

Which do I choose?

There’s no right or wrong strategy to use. The single-key strategy is the default because it should feel most familiar to developers. However, it doesn’t leverage the massive scaling potential of the cloud. It’s definitely a topic that deserves some up-front consideration before starting development. If nothing else, read through Section 3 of the whitepaper to familiarize yourself enough with partitioning to make an educated decision.

Azure Table Storage Associations with RIA Services

2010-11-19T15:28:22Z

For this post, I’ll assume you read my intro to Windows Azure Table Storage. If not, take a second to read it. This time around I’m skipping past the contextualizing.

In my first entry, I showed how to get a simple entity all the way from Table Storage to Silverlight. It was a necessary step, but you’ll need to know more to write an application. This time around, I want to walk through creating two related tables; one with a reference to the other. All the code here will be things you need to write for your Web Role project. This sample follows a three-step pattern you’ll find yourself using over and over as you write WCF RIA Services applications that use Windows Azure Table Storage.

Step 1: Define your Entities

We’ll stick to a couple simple entities with a parent-child relationship where the parent has a collection of children.

  public class MyParentEntity : TableEntity
  {
    public MyParentEntity()
    {
      this.Children = new List<MyChildEntity>();
    }

    public string MyParentName { get; set; }

    [Include]
    [Association("Parent_Child", "PartitionKey,RowKey",
      "ParentPartitionKey,ParentRowKey")]
    public List<MyChildEntity> Children { get; set; }
  }

  public class MyChildEntity : TableEntity
  {
    public string MyChildName { get; set; }

    [Association("Parent_Child", "ParentPartitionKey,ParentRowKey",
      "PartitionKey,RowKey", IsForeignKey = true)]
    public MyParentEntity Parent { get; set; }
    public string ParentPartitionKey { get; set; }
    public string ParentRowKey { get; set; }
  }

In case you aren’t familiar with all the ins-and-outs of entity modeling, I’ll run down the details. As a point of reminder, all table storage entities are keyed by the PartitionKey and RowKey properties defined in the TableEntity base class.

MyParentEntity has a collection of MyChildEntity entities with two attributes; Include and Association. The IncludeAttribute tells RIA Services that the collection of children can be included in serialization. It may feel like a redundant step, but it protects you from sending more data than you intend to. The AssociationAttribute defines how the parent and child entities are related. On the parent, it is created using (1) the association name, (2) the key properties on the parent, and (3) the foreign-key properties on the child that point to the key properties on the parent.

MyChildEntity has three properties that it uses to reference the parent. The Parent property contains the mirror image of the AssociationAttribute found in MyParentEntity. This time the association is created using (1) the association name, (2) the foreign-key properties on the child that point to the key properties on the parent, (3) the key properties on the parent, and (4) setting the IsForeignKey property to true to identify the child entity as the one with the foreign-key properties.

One important point to highlight with entity modeling is we can successfully use property types that are not supported by table storage. For example, since List<MyChildEntity> on MyParentEntity is not a supported type, the serializer will only send the PartitionKey, RowKey, Timestamp, and MyParentName to the database. The important inverse of this is that because the list is not stored in the database we will have to re-populate it when sending our parent entities to the client (more on that later).

Step 2: Define your EntityContext

This second step is fairly easy. We’ll need to create an entity context to use in our domain service. In this case we expose two properties; one for the parents and one for the children.

  public class MyEntityContext : TableEntityContext
  {
    public MyEntityContext() : 
      base(RoleEnvironment.
             GetConfigurationSettingValue("DataConnectionString"))
    {
    }

    public TableEntitySet<MyParentEntity> MyParentEntities
    {
      get { return base.GetEntitySet<MyParentEntity>(); }
    }

    public TableEntitySet<MyChildEntity> MyChildEntities
    {
      get { return base.GetEntitySet<MyChildEntity>(); }
    }
  }

Step 3: Define your DomainService

In this last step we’ll create a domain service and add some logic to read and write to our tables.

  [EnableClientAccess()]
  public class MyDomainService : TableDomainService<MyEntityContext>
  {
    public IQueryable<MyParentEntity> GetMyParentEntities()
    {
      return this.EntityContext.MyParentEntities;
    }

    public IEnumerable<MyParentEntity> GetMyParentEntitiesWithChildren()
    {
      IEnumerable<MyParentEntity> parents =
        this.EntityContext.MyParentEntities;
      IEnumerable<MyChildEntity> children =
        this.EntityContext.MyChildEntities;

      // Hook the association properties together
      foreach (MyParentEntity parent in parents)
      {
        foreach (MyChildEntity child in children)
        {
          if ((parent.PartitionKey == child.ParentPartitionKey) &&
              (parent.RowKey == child.ParentRowKey))
          {
            parent.Children.Add(child);
            child.Parent = parent;
          }
        }
      }

      return parents;
    }

    public void AddMyParentEntity(MyParentEntity entity)
    {
      this.EntityContext.MyParentEntities.Add(entity);

      // Make sure the child entities get the updated keys
      foreach (MyChildEntity child in entity.Children)
      {
        child.ParentPartitionKey = entity.PartitionKey;
        child.ParentRowKey = entity.RowKey;
      }
    }

    public void DeleteMyParentEntity(MyParentEntity entity)
    {
      this.EntityContext.MyParentEntities.Delete(entity);

      // Delete the child entities
      IEnumerable<MyChildEntity> children =
        this.EntityContext.MyChildEntities.Where(c =>
          (c.ParentPartitionKey == entity.PartitionKey) &&
          (c.ParentRowKey == entity.RowKey));

      foreach (MyChildEntity child in children)
      {
        this.EntityContext.MyChildEntities.Delete(child);
      }
    }

    public void UpdateMyParentEntity(MyParentEntity entity)
    {
      this.EntityContext.MyParentEntities.Update(entity);
    }

    public IQueryable<MyChildEntity> GetMyChildEntities()
    {
      return this.EntityContext.MyChildEntities;
    }

    public void AddMyChildEntity(MyChildEntity entity)
    {
      this.EntityContext.MyChildEntities.Add(entity);
    }

    public void DeleteMyChildEntity(MyChildEntity entity)
    {
      this.EntityContext.MyChildEntities.Delete(entity);
    }

    public void UpdateMyChildEntity(MyChildEntity entity)
    {
      this.EntityContext.MyChildEntities.Update(entity);
    }
  }

Starting with the simplest part, with this association we were able to use all the standard methods for reading, adding, updating, and deleting MyChildEntity. Also, updating MyParentEntity didn’t require any additional logic.

In GetMyParentEntitiesWithChildren, we’re filling in the relationship properties (like I alluded to earlier). We’re looking for parents and children where the association properties match and tying them together. After adding the parent to the entity set in AddMyParentEntity, we’re iterating through all the children we’re adding as part of the same change set and updating their foreign-key properties. Finally, in DeleteMyParentEntity we’re looking up all the children associated with the parent and deleting them.

In this post I’ve shown the basics for creating related tables. Hopefully the samples highlight the kind of code required to work with table storage and gets you on your way to writing a cloud app.

Silverlight TV: RIA Services Q & A

2010-11-12T23:40:00Z

John and I went through four questions we see frequently on the WCF RIA Services forum. Here’s our episode and some notes to go along with it.

Silverlight TV: Episode 52

How do I investigate exceptions thrown from my DomainContext?

If you’ve been using RIA, you’ve undoubtedly seen this exception before.

Load operation failed for query 'GetEmployees'. Exception of type 'System.ServiceModel.DomainServices.Client.DomainOperationException' was thrown.
at System.ServiceModel.DomainServices.Client.WebDomainClient`1.EndQueryCore(IAsyncResult asyncResult)
at System.ServiceModel.DomainServices.Client.DomainClient.EndQuery(IAsyncResult asyncResult)
at System.ServiceModel.DomainServices.Client.DomainContext.CompleteLoad(IAsyncResult asyncResult)

A rough translation is “An exception was thrown in your DomainService while loading data.” The problem is this exception is opaque and masks the real failure. What we need is some way to get the details about what is actually occurring.

Option 1: Temporarily set the customErrors mode to “Off”

In your web.config file, you can update the customErrors element.

  <customErrors mode="Off"/>

Option 2: Use fiddler to look at the response from the server

There’s a lot to know about using fiddler, but I’ll keep this section sparse. I showed a little in the video and there are plenty of other examples.

Download Fiddler
Tips for using Fiddler on localhost

Option 3: Override DomainService.OnError to inspect the error on the server

There are a number of reasons to override OnError (logging, etc.) in your DomainServices. One of the ways it can be useful is to give you a place to inspect errors before they’re sent back to the client.

Using any of these method, we can get more useful information from the error.

Load operation failed for query 'GetEmployees'. Object reference not set to an instance of an object.
at SampleBusinessApplication.Web.EmployeeDomainService.GetEmployees() in …\EmployeeDomainService.cs:line 22
at GetEmployees(DomainService , Object[] )
at System.ServiceModel.DomainServices.Server.ReflectionDomainServiceDescriptionProvider.ReflectionDomainOperationEntry.Invoke(DomainService domainService, Object[] parameters)
at System.ServiceModel.DomainServices.Server.DomainOperationEntry.Invoke(DomainService domainService, Object[] parameters, Int32& totalCount)
at System.ServiceModel.DomainServices.Server.DomainService.Query(QueryDescription queryDescription, IEnumerable`1& validationErrors, Int32& totalCount)
at System.ServiceModel.DomainServices.Hosting.QueryProcessor.Process[TEntity](DomainService domainService, DomainOperationEntry queryOperation, Object[] parameters, ServiceQuery serviceQuery, IEnumerable`1& validationErrors, Int32& totalCount)
at System.ServiceModel.DomainServices.Hosting.QueryOperationBehavior`1.QueryOperationInvoker.InvokeCore(Object instance, Object[] inputs, Object[]& outputs)

How do I add a ComboBox to a DataGrid or DataForm?

I have a couple posts that cover these topics.

Silverlight ComboBox Frequently Asked Questions
Silverlight ComboBox Sample for RIA Services

How do I change the default metadata added to an Entity when using the LinqToEntitiesDomainService?

It’s worth taking a second to provide context for this question. When you use the LinqToEntitiesDomainService, RIA Services codegen will add some default metadata to your entity types. For instance, if we look at the generated code for our Employee type, we can see the metadata on the FirstName property.

  [DataMember()]
  [Required()]
  [StringLength(10)]
  public string FirstName

It’s worth asking “Where do these value come from?” In short, the code generator is looking at the constraints you specified in your database and converting them into attributes. This helps reduce the number of exceptions you encounter when submitting your changes to the database.

If you want to use something other than the default metadata you only need to specify it yourself. All the metadata you specify will override the codegen defaults. For instance, I can add some metadata to the Employee type.

  // The MetadataTypeAttribute identifies EmployeeMetadata as the class
  // that carries additional metadata for the Employee class.
  [MetadataTypeAttribute(typeof(Employee.EmployeeMetadata))]
  public partial class Employee
  {
    internal sealed class EmployeeMetadata
    {
      [Required(AllowEmptyStrings = true,
                ErrorMessage = "First name cannot be null.")]
      public string FirstName { get; set; }
    }
  }

When I do this, I can see the attribute I specified for the FirstName property get generated in place of the default attribute.

  [DataMember()]
  [Required(AllowEmptyStrings=true,
            ErrorMessage="First name cannot be null.")]
  [StringLength(10)]
  public string FirstName

How do I add cross-field validation to an Entity?

Jeff has some great posts on validation. Here are the two that cover cross-field validation.

Cross-Field Validation
Entity-Level Validation

Do you have the sample code?

Yep. Here it is.

How to change the request timeout for WCF RIA Services

2010-11-03T23:52:12Z

My teammate, Jason Cooke, put together this great article on changing the timeout in RIA Services. Hope you find it helpful.

Change Timeouts for WCF RIA Services

WCF RIA Services specifies default timeouts for its endpoints, so you can be sure that all requests complete in a reasonable time, either with success, or a timeout error:

The HTTP request to 'http://<your URL>' has exceeded the allotted timeout. The time allotted to this operation may have been a portion of a longer timeout.

This error comes from the client's underlying WCF endpoint when a long-running request takes longer than the endpoint's SendTimeout, which is one minute by default.

If you get this error, first consider restructuring the operation to enable it to finish sooner. For example, split the operation into multiple parts, or just kick off the operation and poll for completion.

You don't need to change your design, though, because you can extend the client timeout values in RIA Services. The key is to get the endpoint for your domain service (as shown in RIA Services Authentication Out-Of-Browser), and change the timeouts on the endpoint's binding.

  /// <summary>
  /// Utility class for changing a domain context's WCF endpoint's
  /// SendTimeout. 
  /// </summary>
  public static class WcfTimeoutUtility
  {
    /// <summary>
    /// Changes the WCF endpoint SendTimeout for the specified domain
    /// context. 
    /// </summary>
    /// <param name="context">The domain context to modify.</param>
    /// <param name="sendTimeout">The new timeout value.</param>
    public static void ChangeWcfSendTimeout(DomainContext context, 
                                            TimeSpan sendTimeout)
    {
      PropertyInfo channelFactoryProperty =
        context.DomainClient.GetType().GetProperty("ChannelFactory");
      if (channelFactoryProperty == null)
      {
        throw new InvalidOperationException(
          "There is no 'ChannelFactory' property on the DomainClient.");
      }

      ChannelFactory factory = (ChannelFactory)
        channelFactoryProperty.GetValue(context.DomainClient, null);
      factory.Endpoint.Binding.SendTimeout = sendTimeout;
    }
  }

Pass the domain context for the long-running operation and the new value for the send timeout to the ChangeWcfSendTimeout method, and you are good. You cannot change the binding after the endpoint is used, so the best place to call this method is in the domain context's partial OnCreated method, like this:

namespace SampleNamespace.Web.Services
{
  public partial class MyDomainContext
  {
    partial void OnCreated()
    {
      TimeSpan tenMinutes = new TimeSpan(0, 10, 0);
      WcfTimeoutUtility.ChangeWcfSendTimeout(this, tenMinutes);
    }
  }
}

It’s important to make sure the namespaces match when implementing partial methods. The code in this sample should be included in your client project (here it has the name SampleNamespace) and the domain service is SampleNamespace.Web.Services.MyDomainService.

Using the Visual Studio Async CTP with RIA Services

2010-11-02T19:30:16Z

I’ve been excited about this CTP for quite a while now and it’s great to finally have a chance to play with it. Way back in early RIA days we had a number of conversations with the TPL (Task Parallel Library) folks to see if we could use Task<T> with RIA. We were never quite able to sort out the details so now that I’ve finally had a chance to use the two together I’m pretty excited.

Using Async on the Server

As soon as you pick up the Async CTP, you get the idea it can be used everywhere. Asynchronous code becomes just as easy to write as synchronous code, and the performance improvements it offers are tantalizing . It’s all still pretty new, but I’m guessing you’ll find reasons to use it in your DomainServices pretty quickly.

Right now, all DomainService operations are synchronous, so it’s up to you to marry the two worlds. Luckily, Task makes this pretty easy to accomplish. For instance, let’s say you want to use an asynchronous method that returns a Task. To consume it synchronously, all you have to do is write a synchronous method that Waits for the task to complete.

  using RGB =
    System.Tuple<SampleRedEntity, SampleGreenEntity, SampleBlueEntity>;

  [EnableClientAccess()]
  public class SampleDomainService : DomainService
  {
    public IEnumerable<SampleRedEntity> GetRedEntities()
    {
      return this.GetEntitiesSync().Select(t => t.Item1);
    }

    public IEnumerable<SampleGreenEntity> GetGreenEntities()
    {
      return this.GetEntitiesSync().Select(t => t.Item2);
    }

    public IEnumerable<SampleBlueEntity> GetBlueEntities()
    {
      return this.GetEntitiesSync().Select(t => t.Item3);
    }

    private RGB[] GetEntitiesSync()
    {
      Task<RGB[]> task = this.GetEntitiesAsync();
      task.Wait();
      return task.Result;
    }

    private async Task<RGB[]> GetEntitiesAsync() {…}
  }

Using Async in Silverlight

In Silverlight, using Async becomes a little more interesting for two reasons; (1) You’re already forced to use async, and (2) RIA Services provides an async model similar to Task<T>.

My first step in integrating the CTP with RIA was to create a simple extension method to consume our RIA operations (LoadOperation<T>, etc.) as Tasks. I played around with different variations, but in the end it turned out to be quite simple.

  public static class OperationExtensions
  {
    public static Task<T> AsTask<T>(this T operation)
      where T : OperationBase
    {
      TaskCompletionSource<T> tcs =
        new TaskCompletionSource<T>(operation.UserState);

      operation.Completed += (sender, e) =>
      {
        if (operation.HasError && !operation.IsErrorHandled)
        {
          tcs.TrySetException(operation.Error);
          operation.MarkErrorAsHandled();
        }
        else if (operation.IsCanceled)
        {
          tcs.TrySetCanceled();
        }
        else
        {
          tcs.TrySetResult(operation);
        }
      };

      return tcs.Task;
    }
  }

To give some context on the next part, here’s the UI I’m using. It’s just a few DataGrids bound to the EntitySets on my DomainContext. I’ve also included a BusyIndicator to spin while I’m loading everything.

  <UserControl …>

    <UserControl.Resources>
      <web:SampleDomainContext x:Key="sampleDomainContext" />
    </UserControl.Resources>
    
    <Grid x:Name="LayoutRoot" Background="White">
      <toolkit:BusyIndicator Name="busyIndicator">
        <StackPanel>

          <TextBlock Text="Reds" Margin="2" FontWeight="Bold"/>

          <sdk:DataGrid Name="redsDataGrid" IsReadOnly="True"
            ItemsSource="{Binding SampleRedEntities,
                          Source={StaticResource sampleDomainContext}}"/>

          <TextBlock Text="Greens" Margin="2" FontWeight="Bold"/>

          <sdk:DataGrid Name="greensDataGrid" IsReadOnly="True"
            ItemsSource="{Binding SampleGreenEntities,
                          Source={StaticResource sampleDomainContext}}"/>

          <TextBlock Text="Blues" Margin="2" FontWeight="Bold"/>

          <sdk:DataGrid Name="bluesDataGrid" IsReadOnly="True"
            ItemsSource="{Binding SampleBlueEntities,
                          Source={StaticResource sampleDomainContext}}"/>

        </StackPanel>
      </toolkit:BusyIndicator>
    </Grid>
  </UserControl>

Finally, here’s where I get to do all the neat stuff.

  public partial class MainPage : UserControl
  {
    private readonly SampleDomainContext _context;

    public MainPage()
    {
      InitializeComponent(); ;

      this._context =
       (SampleDomainContext)this.Resources["sampleDomainContext"];

      this.InitializeData();
    }

    private async void InitializeData()
    {
      this.busyIndicator.IsBusy = true;

      // Serial
      await this._context.Load(
              this._context.GetRedEntitiesQuery()).AsTask();
      await this._context.Load(
              this._context.GetGreenEntitiesQuery()).AsTask();
      await this._context.Load(
              this._context.GetBlueEntitiesQuery()).AsTask();

      // Parallel
      await TaskEx.WhenAll(
        this._context.Load(this._context.GetRedEntitiesQuery()).AsTask(),
        this._context.Load(this._context.GetGreenEntitiesQuery()).AsTask(),
        this._context.Load(this._context.GetBlueEntitiesQuery()).AsTask()
        );

      this.busyIndicator.IsBusy = false;
    }
  }

I’ve made the InitializeData method async so it starts to run in the constructor, but finishes well after. As you can see, I set the busy indicator to busy before loading data and then ,when all the data is successfully loaded, I set it to idle again. Also, I’ve shown two approaches for invoking multiple queries. First, I show how Loads can be invoked serially such that each is only started after the previous one completes. Next, I show how all the Loads can be run in parallel. The WhenAll method will ensure all the loads have completed successfully before I set my busy indicator to idle.

This is just a small sample of the things you can do with the Async CTP, but I’m already a big fan. Hopefully you find this helpful, and please let me know if you have any questions.

Silverlight ComboBox Frequently Asked Questions

2010-11-02T15:20:37Z

I’ve wanted to do a follow up to my original ComboBox post for a while now. I answered a number of the questions throughout the comments, but I thought I’d gather all the answers up and add some nice code samples. Hope this helps.

How do I use a ComboBox in a DataForm?

For most of the scenarios where you’ll be using a ComboBox in a DataForm a static data source will be sufficient. In our case, let’s assume we’re pulling a list of options from the server. We’ll add a method to our DomainService to get these items.

  public IEnumerable<string> GetCountryStrings()
  {
    return new[] { "UK", "USA" };
  }

Our next step is to create a data source to call the method. We can add the following snippet to our Silverlight page.

  <navigation:Page.Resources>
    <web:EmployeeDomainContext x:Key="employeeDomainContext"/>
    <ex:ComboBoxDataSource x:Key="countryDataSource"
      DomainContext="{StaticResource employeeDomainContext}"
      OperationName="GetCountryStrings" />
  </navigation:Page.Resources>

It’s worth noting that we’ve made both the DomainContext and ComboBoxDataSource resources. This will allow us to share the DomainContext with the data source we use to load our data. Specifically, when we add a DomainDataSource that loads the entities, we’ll make sure that is uses the DomainContext declared in the resources.

  <dds:DomainDataSource AutoLoad="True"
    Name="employeeDomainDataSource"
    DomainContext="{StaticResource employeeDomainContext}"
    QueryName="GetEmployeesQuery" />

The final step in using a ComboBox within a DataForm is to hook everything together within a DataField.

  <toolkit:DataForm AutoGenerateFields="False"
    ItemsSource="{Binding ElementName=employeeDomainDataSource, Path=Data}"
    Name="employeeDataForm">
    <StackPanel>
      <toolkit:DataField Label="Title">
        <TextBox Text="{Binding Path=Title, Mode=TwoWay}" />
      </toolkit:DataField>
      <toolkit:DataField Label="Country">
        <ComboBox 
          ItemsSource=
            "{Binding Data, Source={StaticResource countryDataSource}}"
          SelectedItem="{Binding Country, Mode=TwoWay}"
          ex:ComboBox.Mode="AsyncEager" />                            
      </toolkit:DataField>
    </StackPanel>                    
  </toolkit:DataForm>

In this case, we’ve bound the ItemsSource to our data source, two-way bound the SelectedItem to a property on the entity, and set the ComboBox mode to AsyncEager.

It’s also worth noting we’ve set the DataField label to “Country”. If we were using the Display or Required attributes, we could set PropertyPath instead to ensure the metadata was applied to the DataField correctly.

Another point to highlight is I’m not using ElementName binding. It’s rarely explained, but ElementName binding has some limitations when used in templates (there are good reasons for this, but I won’t go into them here). It’s best to consider templates as a barrier for ElementName binding. Controls inside the template can bind to other controls inside the template. Controls outside the template can bind to other controls outside the template. However, controls inside the template cannot use ElementName binding to bind to controls outside the template (and vice-versa). This is another reason we chose to make the data source a resource above.

How do I use a ComboBox in a DataGrid?

Using a ComboBox in a DataGrid follows nearly the same pattern as above. First, define an operation on your DomainService to return the items. Second, define a data source to load the items; sharing a DomainContext as necessary. Finally, hook everything together within a DataGridTemplateColumn.

  <sdk:DataGrid AutoGenerateColumns="False"
    ItemsSource="{Binding ElementName=employeeDomainDataSource, Path=Data}"
    Name="employeeDataGrid">
    <sdk:DataGrid.Columns>
      <sdk:DataGridTextColumn x:Name="titleColumn"
        Binding="{Binding Path=Title}" Header="Title" />
      <sdk:DataGridTemplateColumn x:Name="countryColumn" Header="Country">
        <sdk:DataGridTemplateColumn.CellEditingTemplate>
          <DataTemplate>
            <ComboBox
              ItemsSource=
                "{Binding Data, Source={StaticResource countryDataSource}}"
              SelectedItem="{Binding Country, Mode=TwoWay}"
              ex:ComboBox.Mode="AsyncEager" />
          </DataTemplate>
        </sdk:DataGridTemplateColumn.CellEditingTemplate>
        <sdk:DataGridTemplateColumn.CellTemplate>
          <DataTemplate>
            <TextBlock Text="{Binding Path=Country}"/>
          </DataTemplate>
        </sdk:DataGridTemplateColumn.CellTemplate>
      </sdk:DataGridTemplateColumn>
    </sdk:DataGrid.Columns>
  </sdk:DataGrid>

As above, we’ve bound the ItemsSource to our data source, two-way bound the SelectedItem to a property on the entity, and set the ComboBox mode to AsyncEager.

Additionally, you might notice we’ve created two templates. We need to set up the CellEditingTemplate to use a ComboBox, but the CellTemplate used for reading the value can have anything in it. In this case it was easiest to display the value using a TextBlock.

What are the modes Async and AsyncEager and am I using them correctly?

There have been a number of questions along the lines of “I only see the selected item in my pick list. Why aren’t the items loading correctly?” In nearly every case, the inquirer is using the AsyncEager mode and it is masking the underlying failure (which tends to be the SelectedItem isn’t available in the ItemsSource). I figured I’d take a second to explain the modes.

Async mode makes sure the ComboBox’s SelectedItem will be reselected any time the ItemsSource changes. By default the control will stop binding any time the SelectedItem is not in the Items. This can be inconvenient in scenarios where you’re loading the ItemsSource asynchronously as the burden of correctly ordering the load completion and then establishing the binding always falls on you. With the Async mode, the ItemsSource can be loaded before or after the binding is created and the ComboBox will work fine regardless of the order. For this mode, the ComboBox will remain blank with an empty pick list until the ItemsSource is loaded.

AsyncEager mode goes one step farther then Async mode to improve the UI experience by addressing the selection ‘flicker’ that can occur when the ItemsSource is loaded asynchronously. If the SelectedItem is not in the ItemsSource, the ItemsSource will be replaced with a single-item list containing only the SelectedItem. The assumption is that in the near future, the ItemsSource will be updated with a list that does contain the SelectedItem. In this mode, the ComboBox will have a single-item pick list containing only the SelectedItem until the ItemsSource is loaded.

In both modes, it is important to note that equality is often based on referential comparison. Entities loaded in different DomainContext instances are not referentially equal. If you load the ItemsSource in one context and the SelectedItem in another, the entity will not be selected correctly in the ComboBox. For this reason (among others) it is important to share the DomainContext when loading the ItemsSource (see my last post for an example).

RIA Services and Windows Azure Table Storage

2010-11-01T21:40:52Z

We worked right up to the deadline, but I’m happy to say we got a preview of RIA support for Windows Azure Table Storage into the October Toolkit release (that coincides with the SP1 Beta release). You could integrate with table storage previously, but our goal was to make using it as simple as possible. With all the great new Azure features coming down the pipe (announced at PDC10), we want to give you first-class experience using table storage with WCF RIA Services.

Where to Start?

If you’re new to Windows Azure (and to tell the truth, we all fall in that bucket) then you need to start with Jim Nakashima’s blog. I always refer back to it, and it’s proved an invaluable resource. For an introduction to table storage, this post is a good start. The difference between Jim’s approach and what I’ll show here are the steps we take to integrate with existing DomainService patterns. Without further introduction, I’ll jump into the things you need to know to get the most out of our Microsoft.ServiceModel.DomainServices.WindowsAzure assembly preview.

Let’s Get a Project Set Up

We’ll use this section to go step-by-step and set up a clean Silverlight project ready for Azure. If you’re interested in starting with the Business Application Template instead, take a look at this introductory post.

1) Make sure you have the latest Windows Azure SDK installed (http://www.microsoft.com/windowsazure/)

2) Open Visual Studio and create a new Silverlight project with WCF RIA Services enabled

3) Add a Windows Azure Cloud Service project to your solution. When the New Cloud Service Wizard pops up, select ‘Ok’.

4) In your Cloud Service project, Add a Web Role Project from your solution.

In the Wizard, select your Web Application project.

5) The next step is to add the RIA Services reference you need to your Web Application project. My favorite way to do this is to add an empty DomainService using the wizard and then immediately delete it.

6) Finally, we need to make sure our application can be deployed by setting the RIA Services references to ‘Copy Local = True’.

In your web project, make sure to update the reference to both System.ServiceModel.DomainServices.Hosting and System.ServiceModel.DomainServices.Server.

7) Now that we’re ready to go, let’s add the references we’ll need to work with Windows Azure. Add references to System.Data.Services.Client, Microsoft.WindowsAzure.ServiceRuntime, Microsoft.WindowsAzure.StorageClient, and Microsoft.ServiceModel.DomainServices.WindowsAzure to your Web Application project.

You’ll also need to set Copy Local to True for both Microsoft.WindowsAzure.StorageClient and Microsoft.ServiceModel.DomainServices.WindowsAzure.

A Windows Azure Entity

Now that we have a project set up, we can focus on using Windows Azure Table Storage. Windows Azure provides queryable structured storage. You can create an unlimited number of tables which in turn can have an unlimited number of entities. There are a few constraints to the structure, but it’s pretty flexible (for more information take a look at the Table Storage whitepaper). One hard rule is that every entity must have three properties, the PartitionKey, the RowKey and the Timestamp. Together these form a unique key for an entity. Additionally, query results are returned sorted by PartitionKey and then by RowKey.

To make it as simple as possible to define entities, we’ve provided the base class TableEntity that includes these properties. The first step to working with table storage is to define your entity. For this post, we’re starting from scratch and the properties on our entity will define the schema of our table.

  public class MyEntity : TableEntity
  {
    public string MyName { get; set; }
  }

With this small snippet, I’ve defined an entity with four properties; PartitionKey, RowKey, Timestamp, and MyName. Now with an entity in hand, we’ll look at defining a context for working with table storage.

A Context for Table Storage

The second step for getting running with Windows Azure Table Storage is to create a context the DomainService can use. We wanted to create a familiar feel for developers used to working with RIA, so we’ve provided you with two types TableEntitySet and TableEntityContext.

  public class MyEntityContext : TableEntityContext
  {
    public MyEntityContext() : 
      base(RoleEnvironment.
             GetConfigurationSettingValue("DataConnectionString"))
    {
    }

    public TableEntitySet<MyEntity> MyEntities
    {
      get { return base.GetEntitySet<MyEntity>(); }
    }
  }

In the snippet above, we reference a connection string specified in the Web Role configuration. To add a connection string, open the Web Role properties.

Now, with a small snippet of code, we’re ready to write our DomainService.

A Table Storage Domain Service

With our entity defined and our context ready, we can begin to write a DomainService. Once again, we’ve provided you with a base class to start with. The TableDomainService takes care of a lot of the table-storage-specific concerns so you can concentrate on your business logic.

  [EnableClientAccess]
  public class MyDomainService : TableDomainService<MyEntityContext>
  {
    public IQueryable<MyEntity> GetMyEntities()
    {
      return this.EntityContext.MyEntities;
    }

    public void AddMyEntity(MyEntity entity)
    {
      this.EntityContext.MyEntities.Add(entity);
    }

    public void DeleteMyEntity(MyEntity entity)
    {
      this.EntityContext.MyEntities.Delete(entity);
    }

    public void UpdateMyEntity(MyEntity entity)
    {
      this.EntityContext.MyEntities.Update(entity);
    }
  }

For this sample, I just stubbed out simple CRUD operations. This is only a start, but we’ve now completed everything that’s required to get you up and running with a DomainService that reads and writes to table storage.

The Best Part

The best part is that once you have written your DomainService, all the RIA things you’re familiar with just work. You get change tracking. You get validation. You get the works. For instance, this small snippet uses a DomainDataSource to hook a DataGrid up to your DomainService.

  <UserControl … >

    <StackPanel …>
        
      <dds:DomainDataSource ElementName="myEntitiesDDS" QueryName="GetMyEntitiesQuery">
        <dds:DomainDataSource.DomainContext>
          <web:MyDomainContext />
        </dds:DomainDataSource.DomainContext>
      </dds:DomainDataSource>
        
      <sdk:DataGrid ItemsSource="{Binding ElementName=myEntitiesDDS, Path=Data}" />

    </StackPanel>
  </UserControl>

This post was just a brief intro, but there was a lot of area to cover. In the next couple of weeks, I’ll try to flesh out some of the scenarios where things get a little more interesting. Also, if there are any Azure-related topics you’re curious about or want to see covered, just let me know and I’ll try to include them.

Improved binding support in EntitySet and EntityCollection

2010-10-28T20:16:22Z

For our WCF RIA Services V1.0 SP1 Beta release we were finally able to improve binding support for EntitySets and EntityCollections. In our V1 release, EntitySet and EntityCollection did not support adding and removing entities through the IEditableCollectionView interface when used as the ItemsSource in a DataGrid or DataForm. While the details of the problem will only be familiar to some, if you’ve had difficulty adding or removing in a master/details scenario, this is the likely cause.

A Master/Details Example

In this section, I’ll put together a short sample showing how this feature enables a simple master/details scenario. I want to focus mainly on the client side of things so we’ll keep the DomainService simple.

  [EnableClientAccess]
  public class SampleDomainService : DomainService
  {
    public IEnumerable<SampleEntity> GetEntities() {…}

    public void CreateEntity(SampleEntity entity) {…}

    public void UpdateEntity(SampleEntity entity) {…}

    public void DeleteEntity(SampleEntity entity) {…}
  }

  public class SampleEntity
  {
    [Key]
    public int Id { get; set; }

    public string Name { get; set; }
  }

When the RIA Services codegen runs, it will generate the SampleDomainContext and SampleEntity types on the client. I’ve omitted most of the generated code, but here are the two members we’ll use later in the sample.

  public class SampleDomainContext : DomainContext
  {
    public EntitySet<SampleEntity> SampleEntities
    {
      get {…}
    }
    
    public EntityQuery<SampleEntity> GetEntitiesQuery() {…}
  }

My approach on the client side of the application is simple. I use a DataGrid to show a list of the SampleEntities and the DataForm to add, remove, and edit. I’ve defined my SampleDomainContext in the xaml to make the binding simple and explicit.

  <UserControl …>

    <UserControl.Resources>
      <web:SampleDomainContext x:Key="myDomainContext"/>
    </UserControl.Resources>

    <StackPanel x:Name="LayoutRoot" Background="White">
      <StackPanel Orientation="Horizontal" Margin="2">


        <sdk:DataGrid Name="myDataGrid"
          ItemsSource="{Binding SampleEntities,
                        Source={StaticResource myDomainContext}}" 
          IsReadOnly="True" />

        <toolkit:DataForm Name="myDataForm" Width="200"
          ItemsSource="{Binding SampleEntities,
                        Source={StaticResource myDomainContext}}"
          CurrentItem="{Binding SelectedItem,
                        ElementName=myDataGrid, Mode=TwoWay}"
          CommandButtonsVisibility="Add,Delete,Commit,Cancel" />

      </StackPanel>
        

      <Button Name="Submit" Content="Submit Changes" Click="Submit_Click"
        HorizontalAlignment="Left" Margin="2"/>

    </StackPanel>
  </UserControl>

The code behind is just as simple. I pull the SampleDomainContext from the resources (that I declared in xaml) and use it to load and save the SampleEntities. The only complexity here is tracking the DataForm’s Editing state to make sure the edit is committed and the validation errors are addressed before submitting changes.

  public partial class MainPage : UserControl
  {
    private readonly SampleDomainContext _context;
    private bool _isDataFormEditing;

    public MainPage()
    {
      InitializeComponent();

      this._context =
        (SampleDomainContext)this.Resources["myDomainContext"];
      this._context.Load(this._context.GetEntitiesQuery());

      // This is an unfortunate workaround to track the
      // DataForm Editing state
      this.myDataForm.AddingNewItem +=
        (sender, e) => this._isDataFormEditing = true;
      this.myDataForm.BeginningEdit +=
        (sender, e) => this._isDataFormEditing = true;
      this.myDataForm.EditEnded += 
        (sender, e) => this._isDataFormEditing = false;
    }

    private void Submit_Click(object sender, RoutedEventArgs e)
    {
      if (!this._isDataFormEditing || this.myDataForm.CommitEdit())
      {
        this._context.SubmitChanges();
      }
    }
  }

In the end, I have a nice little Master/Details application.

To Sum it Up

This sample is pretty simple. The point I really want to emphasize here is that you can now bind EntitySets and EntityCollections to Silverlight controls like the DataGrid and DataForm and have them work like you would expect them to. On top of that, these types will show improved compatibility in features like drag-and-drop and as well as in third party controls.

WCF RIA Services V1.0 SP1 Beta Released

2010-10-28T14:12:52Z

WCF RIA Services V1.0 SP1 Beta along with WCF RIA Services October toolkit are now both available and ready to go live. You can download them from http://silverlight.net/riaservices.

Check out these blogs for all the details.

Later this week I will be looking deeper into two new features; EntitySet and EntityCollection binding support and Windows Azure Table Storage integration. Stay tuned because this new stuff is awesome.

My Thoughts on an MVVM-friendly DomainDataSource

2010-09-17T16:08:04Z

The DomainDataSource (DDS) could be a great example of an aggregate component. It has a simple public API and does a lot of awesome things at the flip of a switch. The only problem with the thought is there’s little-to-no aggregation going on. All the composition that occurs is hidden behind a wall of internal API. This is especially frustrating for MVVM development where a lot of what the DDS does is not as useful.

In creating an MVVM-friendly DDS we have to figure out the primary components and how they work together. Here’s a rough sketch of where I imagine this design will go. This pattern is so well-worn, I’d almost feel guilty deviating from it.

Even with something so familiar as the base, there are a ton of features to pack in. Here are the set I considered with a few ‘cut’ lines drawn through for priority. High-priority features are the bare essentials for an MVVM-friendly DDS. Medium-priority features are great, but not critical. Low-priority features are things I’ll consider but will probably never get to. Please let me know if you think something needs to be added, removed, or moved to a different priority level.

===== High Priority =====

Source: EntitySet – Using an EntitySet with the rest of the features.
Source: EntityCollection – Using an EntityCollection with the rest of the features.
Source: Read-Only Collection – Using a read-only collection with the rest of the features.
Source: Mutable Collection – Using a mutable collection with the rest of the features.

Server: Sorting – Applying sorting to the data on the server.
Server: Grouping – Applying grouping to the data on the server.
Server: Paging – Applying paging to the data on the server.

Editing: Adding – Adding a new Entity to the source collection.
Editing: Removing – Removing an Entity from the source collection.

Testing: Component Base Classes – Abstract base classes for individual components.

Designer: View – Any view property can be set in xaml using a designer.

Quality: Toolkit – High-quality, partially-supported features.

===== Medium Priority =====

Client: Filtering – Applying a filter to the source collection on the client.

Server: Filtering – Applying a filter to the data on the server.

Query: Dynamic ‘And’ – Creating an EntityQuery using ‘And’ from a dynamic set of filters on the client.
Query: Dynamic ‘Or’ – Creating an EntityQuery using ‘Or’ from a dynamic set of filters on the client.
Query: Nested – Creating an EntityQuery with nested clauses from a dynamic set of filters on the client.
Query: Shaping– Creating an EntityQuery from a dynamic set of sorts, groups, or paging parameters on the client.

Other: Strong-Typing – Strongly-typed API for Entity interaction.
Other: Source Code – Feature source code.
Other: Samples – Feature samples.

Quality: Framework – High-quality, fully-supported features.

===== Low Priority =====

Client: Sorting – Applying sorting to the source collection on the client.
Client: Grouping – Applying grouping to the source collection on the client.
Client: Paging – Applying paging to the source collection on the client.

Loading: Auto – Tracking changes that affect the query and automatically reloading.
Loading: Timed – Reloading based on a timed interval.
Loading: Incremental – Incrementally loading a large data set in smaller blocks.

Testing: Top-level Interfaces – Interfaces for the top-most aggregate objects.
Testing: Component Interfaces – Interfaces for individual components.

Designer: Filtering – Defining filters in xaml using a designer.
Designer: Sorting – Defining sorts in xaml using a designer.
Designer: Grouping – Defining groups in xaml using a designer.

Other: Hot-Swapping – Switching between client and server data shaping during use.

Quality: Preview – Medium-quality, mostly unsupported features; as soon as possible.

What is an MVVM-friendly DomainDataSource?

2010-09-01T15:30:00Z

The second most requested feature on our WCF RIA Services Wish List is an MVVM-friendly DomainDataSource. The neat part about this request is that it means many different things to many different people. The challenge in addressing it is to figure out what are the most valuable changes that will satisfy the greatest number of scenarios.

This is where I turn to you. I’d love to hear some opinions about what people think is important. For now, let’s keep the discussion constrained to two questions.

What are the two most important changes for us to make to the DomainDataSource to make it MVVM-friendly?
If those changes were made, would you use the DomainDataSource in your View Models?

I know there’s more on this topic to talk about, but let’s start slow. I've started this thread on the forum to discuss the issue.

Authorization Sample 305 – Permission-Based Authorization for Silverlight

2010-08-31T16:29:26Z

In Authorization Sample 301 I explained the ins-and-outs of the authorization sample and offered a few hints as to how it could be used. In this post, I will show a specific example where I show how to extend the authorization library to support read and write permissions.

Permissions

The first challenge with this sample was to figure out how to represent permissions in metadata in a way that could be used by AuthorizationAttributes. After churning the design for a while, I came away with something simple that made authorization convenient.

The first step was to create a Permission, a type that combines a name and a list of allowed activities. The name property needs to be treated as the unique key for the permission.

  public class Permission
  {
    public string Name { get; }
    public PermissionKind Kind { get; }
  }

The next step was to define the all the activity types in a PermissionKind enumeration.

  [Flags]
  public enum PermissionKind
  {
    None = 0x0,
    Read = 0x1,
    Write = 0x2,
    All = Read | Write,
  }

With these two types, I was able to create an AuthorizationAttribute for requiring permissions.

  public class RequiresPermissionAttribute : AuthorizationAttribute
  {
    private readonly IEnumerable<string> _permissionNames;

    public RequiresPermissionAttribute(params string[] permissionNames)
    {
      if (permissionNames == null)
      {
        permissionNames = new string[0];
      }
      this._permissionNames = permissionNames.ToArray();
    }

    public IEnumerable<string> PermissionNames
    {
      get { return this._permissionNames; }
    }

    protected override AuthorizationResult IsAuthorized(
                         IPrincipal principal,
                         AuthorizationContext authorizationContext)
    {
      PermissionKind kind = PermissionKind.All;
      if (authorizationContext.Items.ContainsKey(
                                       typeof(PermissionKind)))
      {
        kind = (PermissionKind)
                 authorizationContext.Items[typeof(PermissionKind)];
      }

      User user = (User)principal;
      foreach (string name in this.PermissionNames)
      {
        Permission permission = user.Permissions.FirstOrDefault(
                                                   p => p.Name == name);
        if ((permission != null) && ((kind & permission.Kind) == kind))
        {
          return AuthorizationResult.Allowed;
        }
      }

      return new AuthorizationResult("User does not have permission.");
    }
  }

It may look a little complex at first, so let’s break it down. First, the RequiresPermissionAttribute is created with a permission name.

  [RequiresPermission("Model")]

To be authorized, the user must have the “Model” permission with PermissionKind.All. Also, like the RequiresRolesAttribute, the attribute can be declared with a list of names. In that case, the user must match at least one of the permissions in the list to be authorized.

Apart from the primary authorization mode, the RequiresPermissionAttribute can be queried for one particular PermissionKind. This allows calling code to determine if the user has only a subset of the PermissionKinds; only PermissionKind.Read, for example. To query for a specific kind, an entry for the kind can be added to the AuthorizationContext.

UI Modes

The second challenge was how to represent permissions with respect to the UI. I found I needed to create a second enumeration to identify the states that were interesting from a UI perspective.

  public enum ReadWriteMode
  {
    None = 0,
    Read,
    ReadOnly,
    ReadWrite,
  }

Read – This mode is designed for switching control visibility on authorization. If the user has the right read permission the control will be visible.
ReadOnly – This mode is designed to work in tandem with ReadWrite. When the user has permission to read but not write the control will be visible.
ReadWrite – This mode works with ReadOnly. When the user has permission to read and write the control will be visible.

The pairing of ReadOnly and ReadWrite allows controls for viewing and editing to be declared alongside each other in the xaml. Setting the mode ensures they will never be visible at the same time.

  <!-- Value -->
  <TextBlock Grid.Row="1" Grid.Column="0"
             Text="Value"
             rws:ReadWriteAuthorization.RequiresPermission="Model"
             rws:ReadWriteAuthorization.Mode="Read" /> 
  <TextBlock Grid.Row="1" Grid.Column="1"
             Text="{Binding Value}"
             rws:ReadWriteAuthorization.RequiresPermission="Model"
             rws:ReadWriteAuthorization.Mode="ReadOnly" />
  <ComboBox Grid.Row="1" Grid.Column="1"
            SelectedValue="{Binding Value, Mode=TwoWay}"
            rws:ReadWriteAuthorization.RequiresPermission="Model"
            rws:ReadWriteAuthorization.Mode="ReadWrite" />

Rules, Behaviors, and Sources

Writing a permission-based solution takes advantage of (and was a catalyst for) most of the extensibility points in the authorization library. First there is a custom AuthorizationRule that ties the whole thing together. It creates RequiresPermissionAttributes for authorization from the permission names in the attached ReadWriteAuthorization.RequiresPermission dependency property. The rule also creates custom AuthorizationBehaviors that handle updating the UI using the attached Authorization.TargetProperties and ReadWriteAuthorization.Mode dependency properties.

To control the UI behavior, the custom ReadWriteAuthorizationBehavior creates a binding between the target dependency property and a custom AuthorizationSource. Based on the mode, it will bind to one of the Result, ReadOnlyResult, or ReadWriteResult properties on the source.

The ReadWriteAuthorizationSource has three result properties to match up with the ReadWriteMode enumeration; Result, ReadOnlyResult, and ReadWriteResult. The default Result property matches up with ReadWriteMode.Read. The source is created with one or more RequiresPermissionAttributes and uses them to authorize the current user and determine each of the results. Also, each of these properties can be listened to for changes and will update in response to changes in WebContext.Current.User.

I hope you’re still following, but that was a lot of types and relationships condensed into a few short paragraphs. In summary, there is a custom AuthorizationRule, a custom AuthorizationBehavior, and a custom AuthorizationSource. Together they work to require permissions and update the UI.

A Custom Rule for Text

One of the benefits of rule extensibility is the control it provides. In this sample, I created a custom rule to apply only to TextBoxes.

  public class ReadWriteTextAuthorizationRule : AuthorizationRule
  {
    public override IEnumerable<AuthorizationBehavior>
                      GetAuthorizationBehaviors(object target)
    {
      return new[]
      {
        new ReadWriteAuthorizationBehavior(
              "Visibility", ReadWriteMode.Read),
        new ReadWriteAuthorizationBehavior(
              "IsReadOnly", ReadWriteMode.ReadOnly),
      };
    }
  }

It uses the custom ReadWriteAuthorizationBehavior to bind the Visibility and IsReadOnly properties to an AuthorizationSource. I chose to make it the default rule for TextBoxes, but it could just as easily be applied to individual controls. Also, since a target can have more than one rule, I can use the ReadWriteAuthorization.RequiresPermission property to define the RequiresPermissionAttributes used for authorization and the default text rule to define the behaviors and binding to apply.

  <TextBox Text="{Binding Text, Mode=TwoWay}"
           rws:ReadWriteAuthorization.RequiresPermission="Model" />

Wrap Up

There’s a lot of code in this sample, but I wanted to show how a more complex authorization scenario could be implemented. I imagine this same design could be scaled up to support more than just Read and Write permissions. For each PermissionKind that was added, one or more corresponding UI Modes could be added as well.

I’ve included the source here for your reference. I hope it’s a helpful reference point for implementing authorization in your own applications.

Authorization Sample 304 – MVVM Authorization for Silverlight

2010-08-31T16:17:00Z

In Authorization Sample 301 I explained the ins-and-outs of the authorization sample and offered a few hints as to how it could be used. In this post, I will show a specific example where I put together an authorized form using the Model-View-ViewModel pattern.

For this form, I created a simple view model with the following properties.

  public class ViewModel : INotifyPropertyChanged
  {
    public int Id { get; set; }

    public ModelValue Value { get; set; }
    public Visibility ValueVisibility { get; private set; }

    public string Text { get; set; }
    public Visibility TextVisibility { get; private set; }
    public bool IsTextReadOnly { get; private set; }

    public ICommand ResetCommand { get; }
  }

My goal was to present a customized view for each user role. To implement this I created a couple AuthorizationSources using AuthorizationAttributes. The benefit of using sources is they subscribe to user changes and apply the attributes to provide an AuthorizationResult that I can bind to in my view model. The _memberSource tells me if the user is a “member”, and the _administratorSource tells me if the user is an “administrator”.

  public ViewModel()
  {
    this._memberSource =
      new AuthorizationSource(
            new[] { new RequiresRoleAttribute("member") });
    this._administratorSource =
      new AuthorizationSource(
            new[] { new RequiresRoleAttribute("administrator") });

    this._resetCommand = new AuthorizationCommand(
                               this._administratorSource,
                               new ResetCommand(this));

    this._memberSource.PropertyChanged +=
     (s, e) => this.CalculateAuthorizedProperties();
    this._administratorSource.PropertyChanged +=
     (s, e) => this.CalculateAuthorizedProperties();

    this.CalculateAuthorizedProperties();
  }

The CalculateAuthorizedProperties method takes the results from each source and uses them to set other view model properties that I’ve bound to in my view.

  private void CalculateAuthorizedProperties()
  {
    this.ValueVisibility =
      (this._memberSource.Result == AuthorizationResult.Allowed) ?
        Visibility.Visible :
        Visibility.Collapsed;
    this.TextVisibility = this.ValueVisibility;
    this.IsTextReadOnly =
      (this._administratorSource.Result != AuthorizationResult.Allowed);
  }

The last bit of the sample to highlight is the _resetCommand. An AuthorizationCommand is created taking an AuthorizationSource and a command to delegate to. When the result on the source is not equal to AuthorizationResult.Allowed, the command’s CanExecute property will be set to false. When the authorization command is allowed, it will delegate to other command passed in to its constructor.

I’ve included the source for the sample here.

In this sample I stuck mostly to AuthorizationAttributes and AuthorizationSources. These are definitely the most interesting types for MVVM authorization, but AuthorizationRules might also prove helpful. For instance, for complex logic like interpreting metadata on an Entity a rule could be used to determine which attributes to pass to the source. That would make the logic both encapsulated and reusable for multiple view models.