Partager via

Simple Azure Service Experience

  • Article

I started a couple of days ago working on my first Azure service and have learned a lot.  It's a cliche, but there is a ton of good information on the web on this.  One of the challenges is wading through it all and piecing together the great information in one blog (but which leaves out a key part) and the good information in another (which fills in that missing piece).

A few things that may be obvious, but weren't to me...

  • If you're using Azure storage, you want to get the StorageClient API - it makes it a lot easier to deal with the Azure storage REST APIs and provides a framework for wrapping these as normal ADO.NET objects.
  • I'm planning on using the table storage from both my "worker role" (think traditional background service on Windows) and "web role" (web-based UI) Azure services, so wasn't quite sure how to get that connected.  The idea is that the background "worker role" will populate the data which the web role will read.  There are a bunch of classes you set up just to enable access to table storage, including:
    • One class per entitity (think of this as like a table in SQL) that models the values in the entity and provides each value as a typed property.  This is how rows are delivered to and from the table storage.
    • One class that provides a data context.  which inherits from the Azure StorageClient class TableStorageDataServiceContext.  This is the Azure equivalent of the ADO DataServiceContext class which provides cached state information.
    • Finally, a class which uses these first two to provide high-level CRUD (create, retrieve, update, delete) methods against the table storage.
  • At first, since I was writing the code to populate the tables, I just added these classes to the Azure Worker Role project in my solution, but as I said, I realized this wasn't ideal since I would need to use them from both the worker and the web role.  I then came across Arjan Einbu's blog post on creating a class encapsulating these which would be shared by worker and web role - doh!  Of course that's what I wanted.  With a bit of moving around files, I was able to create a XxxServiceData class project (File / New / Project / Windows / Class Library) in my solution which encapsulates just the data access, then reference that from the Worker and Web role code.

Some good links are (in addition to those above):