I am using the repository pattern and was wondering about what data type I should return. In my database I have a string that is variable length that needs to be broken up based off of fixed lengths. I was initially thinking of passing out the string and letting the service layer do the parsing based on the lengths of the configured columns. I dont really like the idea of passing a string out of the repository layer, would rather pass out a complete object. Passing out the string seems like not enough separation of responsibility, but having the repository having to go to another method to get how the string should be parsed and doing the parsing seems like too much work for the repo. Any suggestions of what should be the responsibility of the repo and service in this case?
The parsing method could be a private method within your repository class, thus hiding the actual parsing from the public actual repos method. Alternatively, it could be an extension method living in a Util class.
I think you're correct in your thinking about not putting the parsing of that string in the svc layer, since it would seem to violate the SRP.
The Repository should definitely return the Business Object.
As for who should do the parsing, you could do a number of things. Maybe you could use a helper function or something similar to parse the string into the correct format. If it's not going to be useful outside of the repo, you could just refactor the code to make it more readable.
You are correct in asserting that you shouldn't have your Repository class reach out to your service layer, so whatever method of refactoring you take to clean up the repository it should be done at that layer, not any higher.
Since the Repository is supposed to act as a collection of in memory objects, it should return an instance of whatever type of object your application is expecting to deal with. If your application expects a parsed object, you should return that.
Relying on some service to do the parsing is all a part of your infrastructure anyway. In most Repository implementations you have to do something with your persisted data before you return it, so this is a good thing.
For example, if your Repository is returning a Domain layer object, but your persistence is using L2S, you might want to map the L2S data to the domain object. You would need to rely on something outside the repository to do this. Call it a service or whatever, you probably don't want to kluge the repository code with the mapping.
My preferred choice would not to store the the data in a fixed-width delimited string in the first place. :)
The way I think about it is this: Who cares the most about the actual storage of the data? If the string format is an artifact of some legacy system and not an essential part of business logic (i.e. if you were to change storage mechanisms you'd get rid of the string) then hide it behind the repository. If it's an essential part of the data but you are abstracting it from the business logic, put it in the service.
If you do leave it in the repository, you can create a special class for manipulating that string and pass it in (as an interface) to the repository. That way you can unit test the string-handling code like crazy (and reuse it else where if needed) and leave your repository simple.