WAQS Save changes

7 reasons to use WAQS

WAQS documentation

 

Self Tracking Entities

Why using Self Tracking Entities?

I read this post, where you can read “We no longer recommend using the STE template, it continues to be available to support existing applications”.

From this post, alternatives are ASP.NET Web API, WCF Data Services and Entity Framework APIs.

I disagree!

I will explain you why.

 

But before it, we have to reply to one question: what Self Tracking Entities are used for?

When we use Entity Framework in 2 Tiers, EF context tracks changes (transparently) to be able to persist them in SaveChangesAsync method.

But Entity Framework context is not serializable. So EF context tracking is not possible in 3 Tiers application. In addition, in this kind of application, we recommend to have short life context: just the time for the server call.

So how can we track changes in 3-Tiers applications?

To do it, we have three main ways to do it:

  • Unit changes
  • Comparing with DB
  • Sending changes with entities

Unit changes

You expose some unit methods like AddCustomer, UpdateCustomer, RemoveCustomer, etc and you call them when you change anything in the client entities.

 

Comparing with DB

This is an anti-pattern but it is often used so I want to explain why you should not do it.

The idea of it is to compare entities sent from the client with DB values.

In addition of SELECT additional time, it is a big issue for concurrency. Imagine that user1 get an entity e1. Then user2 remove e1. Then user1 want to save his changes on e1. So the entity does no more exist in DB anymore. If the key is not an identity, you have no way to know if it’s a new entity or a removed entity. So you will perhaps insert it when the expecting behavior often is to have an exception in this case.

Sending changes with entities

Unit methods are not usable with graph changes.

Imagine that you call UpdateCustomer method with a customer with two orders. How to know if these orders are unchanged ? new ? updated ? So you have to use one call per added/updated/deleted entity. In addition, note that to manage many to many relationships, we have to add some Add and Remove methods for relationships too.

It could become a pain if you want to save a big graph and it could be very slow if you need hundreds of call to save it.

Then, with many calls, you probably won’t save each changes in the same transaction. What happens if one failed?

So, as you can see, this way (used with REST for example) has many limitations.

 

And that’s why including changes information with entities (what Self Tracking Entities does) is so useful!

Note that WAQS changed Microsoft initial template. For example, WAQS add the list of modified properties in order to be able to update only modified properties and to improve SaveChanges (we will talk about it below).

 

Now I want to talk about msdn suggestions to replace STE.

ASP.NET Web API

I don’t understand this. IMHO, ASP.NET Web API could replace WCF but not STE. In addition, we could use STE with ASP.NET Web API. Perhaps they just wanted to mean REST API but, as I explained previously REST is not good with graph changes.

 

WCF Data Services

WAQS could be see as a concurrent of WCF Data Services and adds a lot of improvements comparing to it so the idea here is not to use it.

One of this improvement is the fact that change trancking is transparent with WAQS thanks to STE.

 

Entity Framework API

It is very complex to use it with a good way and, at the end, you will have to reproduce STE logic (which is complex) if you want to manage graph changes or to use unit methods with issues I described above.

 

IMHO, The main issue for Entity Framework team with STE is the fact that it is not in accordance with Code First logic.

 

I used both of msdn options and I strongly recommend you to use STE if you want to save many changes together.

Update (03/27/2014): After talking about it with different EF actors, I realized that there are many issues with EF STE template but WAQS templates fixed them. That’s probably why we had different point of views about it…

 

Reduce data sent size

Imagine that we have a customer with 100 orders. User changes the customer address and then save changes.

We don’t need to send the customer with its 100 orders to the server.

Orders are useless in this case and all customer properties except Id and Address also.

So, in this case, WAQS only send a new instance of Customer with only these two properties set.

In addition, WAQS sets properties with ConcurrencyMode equals to true.

WAQS also sets validation used properties. So, Imagine you wrote the following Validate specification method:

public static Error ValidateShippedDateMoreThanOrderDate(this Order o)
{
     if (o.ShippedDate < o.OrderDate)
         return new Error {Criticity = Criticity.Error, Message = "Shipped date can't be lower than order date"};
     return null; }


In this case, before saving changes, WAQS will test it only if ShippedDate or OrderDate are modified or if the entity is added.



So, if the entity is modified, WAQS sets ShippedDate and OrderDate in Order instance sent to the server if one of them is modified and none otherwise.



 



Note that if you want to update all properties in order to be sure of properties consistency, you can use MarkAsModified method on your entity.



 



So with WAQS SaveChangesAsync method, you save all changes in the same transaction, in only one call sending as small data as possible.

This entry was posted in 16868, 7674. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>