Working with RIA Services #4: how to make sure you don’t lose your custom methods when your datamodel changes?

When working with RIA Services, a lot of your code is generated automatically, but you’ll still need to write quite a lot of custom methods and you’d typically write them in your DomainService-class.  But what if you add an Entity to your datastore?  What if you want to add some CUD-operations next to the read-operation that’s been generated?  Either you’d have to write the Entity-classes and methods manually (a lot of work for something that could be generated), or you’d have to delete your DomainService and re-add it (so the newly added Entities/Queries get generated), but then you’d lose all the custom methods you’ve written in your DomainService…

Bummer, huh?  Well, luckily, there’s a nice workaround for this!  Imagine you’ve written a DomainService filled with custom queries, ServiceOperations, …, working on an Entity Framework domain model.  All of a sudden, a table has to be added to your domain model, so you need to regenerate your DomainService: delete and re-add, thereby losing your custom methods.  It would be nice if you could just put your custom methods in a seperate file, so deleting the DomainService wouldn’t delete those methods.  And you can!  The magic word here?  Partial classes!

As an example, I’ve changed my demo-app around a bit: it now only shows the customers beginning with a certain string.  To get this behaviour, I’ve added a new query method, GetCustomersByFirstLetters, which accepts a string.  I’m passing this as a query to my LoadOperation when loading the items for my DataGrid:

   1: LoadOperation<Customer> loCustomer = CDC.Load(CDC.GetCustomersByFirstLettersQuery("a"));

But, instead of adding this custom method to the CustomerDomainService.cs-file, I’ve created a new file, and named it CustomerDomainService.partial.cs.  In this file, I define a class like this, and add my new method to it:

   1: public partial class CustomerDomainService : LinqToEntitiesDomainService<AdventureWorksLTEntities>

   2: {

   3:     public IQueryable<Customer> GetCustomersByFirstLetters(string firstLetters)

   4:     {

   5:         return this.Context.Customer.Where(c => c.CompanyName.StartsWith(firstLetters));

   6:     }

   7: }

Notice the “partial” keyword? Now, in my original CustomerDomainService.cs-file, I’ve also changed the class signature to include the “partial” keyword.

   1: [EnableClientAccess()]

   2:     public partial class CustomerDomainService : LinqToEntitiesDomainService<AdventureWorksLTEntities>

When you build and run this, you’ll see the app behaves just as you’d expect it to – but thanks to the fact that the custom method is now in a separate file, you’ll no longer lose it in case you have to recreate your DomainService.  All you have to remember is to add the “partial” keyword to the class definition of your generated DomainService, and you’re done! 🙂

What has happened here?  Well, the “partial” keyword actually tells .NET that your class has been split over multiple class definitions/files.  When you build your app, the compiler will combine all the “partial”-classes with the same signature into one class, just as if they were defined in the same file.

I’m pretty sure the need for deleting & recreating your DomainService will be fixed in one of the next drops (after all, the “Update from Database”-option didn’t exist in the first versions of the Entity Framework either), but until then, this should be quite a handy tip.  Enjoy! 🙂

Adjusted sourcecode has been posted here if you’d want it.