Background: Our app is a fairly straight forward MVC web app that calls a service layer. That layer uses a unit-of-work pattern to access some repositories then pass those objects to a domain level service to perform some logic. It’s very clean and works well for us.
Issue: We now have a case where we get a large chunk of xml from a 3rd party and need to process it. That process it fairly complex and will need to make various repository calls during the process (performance is not a concern). That logic should live in our domain with all the other logic.
Question: Would it be clean to pass an interface to a repository for the domain-level service to access?
I think it’s a design smell to pass an interface to your repository for this kind of a process. Perhaps I’m misunderstanding, but it sounds like the processing on the XML is going to be handled inside the repository. Is that for storage means? Even so, this should be handled by a separate class that is only concerned with processing the XML that would accept an interface to your repository.
The repository should only be concerned with the handling the access to the data stores.
It’s not unusual for a process like this to require several calls to the repository. To ensure that you can property test the XML processing logic, the XML processor should accept an interface to the repository so that you can mock that away and unit test the XML processing by itself