I am writing a repository class with entity framework. One of the method is an update method, which simply updates an entity. The controller does not need the entity. However, from a testing perspective, it may be useful to just return the entity. Than I easily have something to assert. It may be even more useful to return two things (with a value tuple): the saved entity and the number of saved changes. Then I have more to assert. On the other hand, it is an update method, not a read method that sould absolutely return something.

What choice should I make considering the good practices?

  • 2
    Surely if you're testing the echoed back value you're not testing what you actually care about (unless it's an update and then re-retrieve) May 14, 2017 at 6:51

3 Answers 3


You should be returning values because you need them not because it makes testing easier. That being said, it is more valuable to know if the operation succeeded since you already know what's going to be updated. If something goes wrong you can use exceptions to communicate it to the upper layers. Also, I don't think that returning a value representing the number of affected records would provide much value since you'll probably be updating aggregates that have updated children.

  • I agree with you that it should return something. After all, it could fail if someone else deleted the record while you were in the process of updating it. OTOH, making testing easier is a Good Thing because it makes it more likely you will actually write a good test. May 13, 2017 at 23:50

I would say return the new entity. My reasoning has to do particularly with REST, but I think it's reasonable to design a storage layer so that it can easily be used in a RESTful service.

10.2.1 200 OK

The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:

GET an entity corresponding to the requested resource is sent in the response;

HEAD the entity-header fields corresponding to the requested resource are sent in the response without any message-body;

POST an entity describing or containing the result of the action;

TRACE an entity containing the request message as received by the end server.

RFC 2616 - Http Response Codes - Emphasis mine

Since POST requests are expected to return a description of the transaction or the actual resulting entity, it seems very reasonable to make sure your storage layer makes it available.

  • I disagree. Sending the updated data back to the client is usually wasteful. An alternative is a 303 see other response, the target of which can be cached, or even ignored by the client if they only care about success/failure. But it doesn't make sense to mirror a Rest API so closely for a repository. For normal code, the command–query separation principle is more likely to be a useful guide than REST conventions.
    – amon
    May 14, 2017 at 11:00

Separation of concern. At update/save time, what is changed is already known since you need to update. All the logic have to be done in the business part, the io part should not even be aware of what it deal with.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.