Andres and Udi are having a discussion about disconnected applications that has overflowed into the topic of service oriented architecture.
"Now, we need to send those changes to the server, together, because I want them executed in a single transaction. I cannot have a service called 'ModifyOrderCustomerInformation', another 'AddALineToOrder' and 'DeleteLineFromOrder'. I need an 'UpdateOrder' service. You can use a diffgram to do it, or you could build your own change-serialization mechanism.
So, I really don't see how you can build an application the way he suggests. It's very nice from the 'service' point of view, but it's very difficult from the client point of view. The only way I see is to map the UI to the service interface, so the user can 'Change Address' or 'Update Marital Status' as different operations in the UI layer, but I can't let the user 'Modify the Customer'. It's a lot of work, and I seriously doubt that the users will like it." [1]
Here's the thing: if you application is a smart client application and it can work disconnected, then you probably want to be using a service oriented architecture. Andres rightly points out that you don't want 5 different methods for updating an order. Although you technically could do it that way, you probably don't want to be ignoring the transactional context of the conversation or locking tables for significant time periods.
The bottom line is that service oriented architecture is a very different model. When designing your service, you have to look at the tasks that are being performed, not the DB operations. In a traditional application, you might have CreateCustomer, CreateOrder and CreateLineItem methods. Your shopping card would call those three methods and wrap the thing in a transaction and everything works as expected. However, the service oriented approach asks the question, "What is the task that is being performed?" Although technically the user is creating an order and line items and a record for themselves, that is not the task they are performing. The task they are performing is placing an order. So, your service oriented architecture would have a single message called "PlaceOrder" which contains all the information required to place an order. That method returns to the user information regarding whether the order was placed succesfully, not whether each line item was created.
Now, what happens if you want to modify that order? The question I would ask first is, "Why would you do that?" Who is going to be modifying the order? Probably not the user, since they can't modify their own order after it is placed. Maybe a customer service person needs to correct some information such as the shipping address. In that case, we provide a service called "CorrectShippingAddress," not a service called "UpdateShippingAddress." Why? Because the task is correcting a shipping address. The DB operation that happens might be an update, but that's not the task. Is this more work? Slightly. The backend will still have all the update methods you are used to using, so you're not writing a bunch of extra code in the DB. However, this approach is far more powerful. One reason why is that now you have an operation defined and you can control everything about that operation. You know when the call comes in through that method that you have a customer service rep trying to update an order and can build in logic based off of that. A generic update method might have 5-6 different uses, which all contain different conditions for whether or not the operation is valid.
Additionally, this type of service oriented operation allows you to only expose the properties of your data that this specific operation uses. This makes your service a lot easier for 3rd parties to deal with. They know exactly what they need to pass in to your service instead of having 20 fields from your entity, only 5 of which they actually use for this operation.
So, I have to disagree with Andres and agree with Udi. It actually isn't a lot more work. It takes a bit more thinking and planning at the service tier, but your data tier won't look any different than it always has. If your development team has more than 1 person, the UI tier should actually be easier to code, since less knowledge is required of the internals of your application and the calls will end up looking a lot like the forms they are creating. Of course, this all assumes that you actually code your UI tier, instead of just binding everything to grids. If you just databind everything to some 3rd party super grid control, then this will complicate things... but hopefully you put a bit more thought into your UI instead of just slapping it together with the latest snazzy grid.
[1] http://weblogs.asp.net/aaguiar/archive/2007/03/30/re-disconnected-problems-and-solutions.aspx