Shawn Excellent article. The best I had read on Astoria so far.

Thanks!
..Ben

hi, there is no EntitySetRights.WriteUpdate in SL2B2SP1, maybe it changed, and it should be EntitySetRights.WriteReplace?

Unruledboy,

Not sure what you mean by SL2B2SP1. The .NET 3.5 SP1 has changed some things in Astoria. I believe EntitySetRights.WriteReplace is correct but that is all on the server so its .NET 3.5 SP1 only. There are some incompatibilities with .NET 3.5 SP1 and Silverlight 2 Beta 2. Once it goes to release it should work better.

yes, I read about the incompatibilities, maybe it is dued to that problem. hope it fixes that ASAP

Thanks for the interesting article, but can Data Services be used for serious enterprise applications?

Essentially the updates are "directly" against the database. All the code that gets executed after calling BeginSaveChanges is generated and does not pass through business logic.

There are ways of intercepting the updates, either within Data Services or the Entity Framework, but is this sufficient?

I also believe that you can add methods to the Data Services service, but these will not accept the data objects as parameters.

I would be interested on your opinion on this as you quite rightly stated "But ORM is about data access, not business rules."

Jason,

Certainly ORM is about data access but on the server Data Services is creating objects and setting properties so if your business logic is part of those objects I would expect this would correctly. Though to be fair your business logic should be on both sides of the pipe (just like in the Web Service story).

The updates are not "directly" against the database. That's the power here. It updates the objects not the database. If you are using a thin ORM wrapper without business logic, it may seem like this, but Data Services is actually executing the changes on the objects themselves. If those objects then save the data to the database without executing business rules, that's up to those objects.

Shawn, One thing that I still have not gotten a good formula for, is data validations. Whether it should be done at Service side or at SL client side. I mean a type of Data Validation that needs to validate against another data within a database. For example, we may have a table that has a series of Min and Max for height/width dimensions. So as the user enters data, the data needs to get validated before the next field.

So in general, what guidelines would you suggest for business logic and data validations, that was something that was missing from your article.

Thanks!
..Ben

Ben,

Like any client, Silverlight should validate data on both sides of the service. Its imperative to think about data validation on the client to help ensure the rules are negotiated with the user; but also on the server to ensure that client-side bugs don't become server-side data inconsistencies.

How exactly entities are serialized to the client when doing a projection? Will the entire entity is serialized first?
Thanks.

Shaun,

From what you have said it sounds like you are advocating implementing the business logic by extending the data objects generated by the EF (using the partial methods exposed etc).

Is this preferable to having a Business Logic Layer through which calls would have to be made?

If this is the case, then how should business logic which isn't an obvious CRUD function be exposed? (For example Transfer(Account accountA, Account accountB, decimal amount)).

Thanks,