I learned a harsh lesson about Visual Studio and saving code snippets in the toolbox yesterday. Knowing that I am not great at coding Entity SQL on the fly, I stuck my code for custom operations in an Astoria Web data service into the VS2008 toolbox. I had two instances of VS open when I did this, so when I closed the instance where I had created the snippets, the instance that was still open is the one that saved the state and they were lost. Note to self: always have a text file with all snippets available when demoing. Oddly, I never used to trust the snippets and only used text files.  I guess I need to get back to a level of cautious (though not rampant) mistrust.

I did surprise myself this morning when I rewrote these from memory and only made one mistake… inserting an “@” where I didn’t need to. I’d call that an A-. It wasn’t a typo, though and it did take a few minute to discover the error which is something I don’t like doing during a conference session, so I just skipped the pain.  (Still only a C+ in my book 🙁 ).

So here, in place of that particular demo, is a post on how to write operations in data services.

The default service provides for all of the capabilities of drilling into, traversing and querying your entities as laid out in this post and in more detail in the Using Astoria document that comes with the downloads and is also on the Astoria site. (Start at http://astoria.mslivelabs.com to find all resources.)

However you can customize your service by providing explicit query operations and also blocking specific query operations. Don’t forget that you can also build views and sprocs into your model. Views are surfaced as EntitySets so they will be no different than other entities (though read-only) in your web service. Stored Procs are a little different. I have to explore how both of those are currently surfaced in Astoria, but would like to wait until we have bits that are not just prototype.

To create a custom operation you need to use the WebGet attribute. Here’s an operation that finds all customers based on the first name of the contact. (I’m using the AW LT database, and am just lazily querying for something that is a direct property of the customer table.)

<WebGet()> _
Public Shared Function CustbyContact(ByVal aw As AdventureWorksLTEntities, ByVal firstname As String) As ObjectQuery(Of Customer)
  If String.IsNullOrEmpty(firstname) Then
  ‘don’t expect to see this nice error if you are testing
  ‘your services in a browser
    Throw New ArgumentNullException(“firstname”, _
     “You must provide a name to search on”)
  End If

  Try
    Return aw.Customer.Where(“it.firstname=@fname”, New ObjectParameter(“fname”, firstname))
  Catch ex As ArgumentException
  ‘this is an opportunity to catch problems with your Entity SQL query when debugging
    Throw ex
  End Try
  End Function

Note that I’m using Entity SQL in this query. While the query

will work if I had used LINQ to Entities for the query, I found that further operators or options such as this example where I additionally sort the response data

http://localhost:50000/WebDataService1.svc/CustbyContact?firstname=Linda&$orderby=CompanyName

do not work unless I have used Entity SQL.

While I have used a WebGet attribute to add additional queries to my service, you can use OnSendEntity and OnReceiveEntity to trap calls to the web service.

This custom operation in my data service prevents any one from querying directly for SalesOrderHeader entities using http://localhost:50000/WebDataService1.svc/SalesOrderHeader.

I can still get at SalesOrderHeaders, for example by requesting customers with the expand option for SalesOrderHeader entities.

The using astoria doc details the key components for creating a method that traps requests and also one that traps POST, PUT and DELETE operations.

I wanted to create a demo of Astoria Data Services being used in a Silverlight app for my ReMix07 Boston session on Tuesday. i have created a little screencast of it in action. Read more here…

I’ve been playing with using EF object in code-behind of aspx web pages.

The first issue to hit is postbacks.

Entity Objects are Binary Serializable so they can be stored in ViewState.

Like many other objects, you need to put your entities into viewstate (I’ll deal with session and application caching in another post). Happily entities can be binary serialized so that happens for free when you add an entity object to ViewState. So you can persist the entities, but you cannot persist the ObjectContext, which is where all of the state information for the objects lives. Frankly, the objectcontext is very expensive and you wouldn’t want that in viewstate anyway.

The outcome of this is that even if you store the objects in viewstate, and pull them back out to attach to a new ObjectContext when you need them again, you will lose any state for the objects.

One saving grace is that objects stored in viewstate get updated automagically during postback. In other words, if I create a cust object and store it in viewstate, then make a change to the cust object, then postback and pull the object back out of viewstate, it will have the newer property values. Viewstate is synced up to the object.

That means we can be sure to have a current version of the object (or list of objects) hanging around as we muck with the page.

Binary Serialization keeps the entire graph in tact

The next piece of the puzzle is that if you have an obect graph (i.e. order with order details or cust with orders with orderdetails) that all gets persisted during binary serialization. That’s a big difference from xml serialization. The big reason is that XML serialization doesn’t know what to do with the relationships, which are also first class objets. The relationships “contain” all of the related data. So binary serialization can handle this. When you get the object graph out of viewstate, it’s got everything in it that it had when it went in.

Updating related data in an object that is in viewstate

This doesn’t act the way you might expect so listen up.

Say I have a  cust object that has orders in it. i have saved the cust object into viewstate. If I edit a property of cust, say FirstName, that’s easy:

cust.FirstName=”Julie”

Viewstate syncs up that change just before the postback.

But what if I want to change something in one of the orders.

You need to do this directly in the cust object, not be extracting the order and changing it.

Here’s what I mean.

My first instinct is to do this:

myOrdtoEdit=(From ord in custs.Orders where ord.OrderID=123 Select ord).First()
myOrdtoedit.ShippedDate=”7/1/2007″

On postback, that new ShippedData is not there.

But if I make the change this way:

cust.Orders.Where(Function(o) o.OrderID = currOrderid).First.ShippedDate=”7/1/2007″

The change is synched up. Good to be aware of.

What about concurrency? What if I need to remember original values?

I think the real solution is going to be is to have original values cached in another layer. But for the sake of working out the concepts, let’s say you are doing everything in code behind. Here’s how I’m solving this problem.

When I first get the values, I want to store them in viewstate, too. But if I do that, and I want to take advantage of the synching viewstate (I think I remember seeing that there is a page directive to turn that off, but don’t hold me to it), then the original objects will get overwritten.

So what I have done was explicitly serialize the original objects and store the resulting memory stream into viewstate. When it’s time to do an update, I deserialize that stream and voila, I have a set of original objects that I can use to compare my current objects to.

I have a post here on how to do an update when you have the original object and current objects available over here.

One object or more? How do I persist multiple objects?

Note that I have wavered between talking about persisting a single object and multiple objects. If you are dealing with a query that returned a collection of objects, then you don’t persist the query. Instead, convert the query to a list with .ToList and you will end up with List<Customer> / List(Of Customer) and that’s what you can put into viewstate. This is also what you would serialize, the list of customer objects.

When do I work with the objects again?

I have done various tests using databinding (gridviews, textboxes) or just manually getting and setting text properties.

Once you post back, the datasource is gone on a bound control anyway. I just work with the text values that are in the control. When I want to update an object, then I will get the object(s) from viewstate and modify them. Other than that, the only time I need them again is when it’s time to do an update back to the data store.