Just trying to get my head round the responsibilities of the service layer and repository layer when saving an object to my persistence store.
My current under standing is this:
In my controller I have created a "Note" object from the data submitted by the user (from the form). The user then calls "Save" on the "NoteService" (which is there via dependency injection).
Within the "Save" method on the "NoteService" I carry out my business logic validation and then pass the "Note" object to the "Save" method of the "NoteRepository".
The "Save" method of the "NoteRepository" then checks to see if there is an existing primary key on this object and if so then get's that object from the db and updates it's properties using the "Note" object passed through and it's then saved back to the db. If there is no primary key then the object is simply saved to the db and the then returned to the service with it's newly created primary key.
Your separation of concerns sounds pretty good to me. We follow the same pattern, but tend to add one more layer right about the repository layer. We call it the domain layer and perform all our business logic in there. Our service layer is just a pass through to our domain in case we need to publish any of our services to an ESB in the future.
The biggest benefit of what you are doing is not cluttering all the business and DB logic in the controller which a lot of people tend to do. You always want your controllers to be as light as possible if you really want to follow MVC.
来源：https://stackoverflow.com/questions/3037605/responsibilities-of-service-and-repository-layers