Currently working on a project, new product, using MVC. I've written a few of these, and I've found doing a repository pattern with "specialized" generic services (GetObjectService< T >, UpdateObjectService< T >, etc). This allows for those special instances of "hey, I need to get something based on this stuff" that's fairly complex and needs to be tested for maintainability reasons. All good stuff, works really well, lots of reusability comes out of doing it this way. I like that.
A problem showed up when we were asked "why does the controller have a dependency on the data layer entity?". The controllers would have a _getObjectService< Something > and have calls to it, the results moving into the ViewModel's in some way or another. My argument for this was simple - the controller knows what to do with that data and turn it into what it needs and regardless of it's (controller) dependency, you'll be coupled to an entity/object/model/something somewhere so defering the execution of a "get" (maybe adding in a simple orderby) is completely ideal. We were immediately shot down, and asked to put a translator in the service layer because of the issue with the dependency on the entity in a controller.
This then grew into a larger problem of "what does this mean for us" and it kinda sucks. Each individual entity needs a full repository for each ... service model and this feels very ...mmm, sub optimal. I understand the idea behind each n-layer isn't dependent past its borders but this seems silly. For instance, I don't need a full repository when I'm simply just calling data.
Anyway, I guess my question is two fold, 1, have you ran into this and how did you handle it and 2, is my argument of "let the app make the decision" incorrect, displaced or flat out wrong?