I have a service oriented architecture. The client holds a list of parent and child dtos that are bound to the front end. The service for this is a get that returns the full list of everything.
When deleting is it better to:
a. remove the object from the list on the front end on success of the service delete method (return bool for success or fail)
b. return the full list of objects again
c. return just the parent and children that were effected
d. other suggestion
Thanks in advance
To have a truly service-oriented architecture, services should be asynchronous, so they shouldn't return any results at all.
For a Delete operation, this is pretty simple to implement: just fire and forget.
Udi Dahan's blog is a good place to learn about real service-orientation.
If you would like to stay with the RPC message exchange pattern implid by your question, I would still say that the method should return void. If you get an empty answer back from a synchronous HTTP POST, it implies success - otherwise, you will get a SOAP Fault or other error result.
I would go with option A. If your service can be relied on to correctly indicate success or failure of the deletion then why bother reloading all the objects? Unless of course you also want to immediately show deletions by other users, in which case B would be the better option. You may also choose to show deletions by other users by a periodic polling/notification method, separate to deletion actions. It really depends on the requirements of your application.
It actually depends on the business case.
When two users are using the system. Both are adding and deleting items from the list.
When user A deletes and item, do you want him to see the chenges from user B, or is it required that user A presses refresh to see these changes?
Ask the users how they want it to work, then choose the method that will give this with the least amount of data transfered over the network.
Not only does it depend on the business case as indicated by this answer, it also depends on your level of risk tolerance in the code's design. Tight coupling between the client and the service can make the code more difficult to change as the application grows and increases in complexity. Instead, a clean separation of responsibilities and loose coupling generally increases maintainability and overall project agility.
In this case, that would probably mean the service wouldn't know about the existence of the client and it's implementation, so that would rule out the service directly manipulating the client list. If this service is implemented as a class library, I would recommend a publisher/subscriber approach, where the service exposes a C# event of a type that includes pertinent deletion information, and the client handles that event and updates it's list accordingly.
If this is a web (one-way) service, I would expect the a deletion service call to be separate of a GetAll service call. The client would manually manage it's list using a combination of those calls.