Return to Answer

You should return exactly what using clients need.

If you believe in the solid principles the two worth considering here are Interface Segregation (depend only on what you need) and Dependency Inversion Principle (depend on abstractions, not on concretions).

Design your methods so that code that uses them can follow these principles.

Why? Because when you follow the ISP you make your needs clear. That keeps your options open about what can fulfill them. Because when you follow DIP changes are less likely to impact you since you depend on stable abstractions not volatile concretions. Which lets you change the concretions with little pain.

I will have to reimplement all the methods in the IQueryable.

If you really need all those methods you can compose yourself of, and delegate to, something that already implements them. It’s a bit of keyboard typing but very flexible.

If you don't really need all those methods you can still compose and delegate to something that already implements them. Prune what you expose back to what's really needed. Done this way you can add more as needed until you stabilize your interface, and later refactor to squeeze out implementations that are not needed.

You should return exactly what using clients need.

If you believe in the solid principles the two worth considering here are Interface Segregation (depend only on what you need) and Dependency Inversion (depend on abstractions, not on concretions).

Design your methods so that code that uses them can follow these principles.

Why? Because when you follow the ISP you make your needs clear. That keeps your options open about what can fulfill them. Because when you follow DIP changes are less likely to impact you since you depend on stable abstractions not volatile concretions. Which lets you change the concretions with little pain.

I will have to reimplement all the methods in the IQueryable.

If you really need all those methods you can compose yourself of, and delegate to, something that already implements them. It’s a bit of keyboard typing but very flexible.

If you don't really need all those methods you can still compose and delegate to something that already implements them. Prune what you expose back to what's really needed. Done this way you can add more as needed until you stabilize your interface, and later refactor to squeeze out implementations that are not needed.

You should return exactly what using clients need.

If you believe in the solid principles the two worth considering here are Interface Segregation (depend only on what you need) and Dependency Inversion Principle (depend on abstractions, not on concretions).

Design your methods so that code that uses them can follow these principles.

Why? Because when you follow the ISP you make your needs clear. That keeps your options open about what can fulfill them. Because when you follow DIP changes are less likely to impact you since you depend on stable abstractions not volatile concretions. Which lets you change the concretions with little pain.

I will have to reimplement all the methods in the IQueryable.

If you really need all those methods you can compose yourself of, and delegate to, something that already implements them. It’s a bit of keyboard typing but very flexible.

If you don't really need all those methods you can still compose and delegate to something that already implements them. Prune what you expose back to what's really needed. Done this way you can add more as needed and later refactor to squeeze out implementations that are not.

You should return exactly what using clients need.

If you believe in the solid principles the two worth considering here are Interface Segregation (depend only on what you need) and Dependency Inversion Principle (depend on abstractions, not on concretions).

Design your methods so that code that uses them can follow these principles.

Why? Because when you follow the ISP you make your needs clear. That keeps your options open about what can fulfill them. Because when you follow DIP changes are less likely to impact you since you depend on stable abstractions not volatile concretions. Which lets you change the concretions with little pain.

I will have to reimplement all the methods in the IQueryable.

If you really need all those methods you can compose yourself of, and delegate to, something that already implements them. It’s a bit of keyboard typing but very flexible.

If you don't really need all those methods you can still compose and delegate to something that already implements them. Prune what you expose back to what's really needed. Done this way you can add more as needed until you stabilize your interface, and later refactor to squeeze out implementations that are not needed.

You should return exactly what using clients need.

If you believe in the solid principles the two worth considering here are Interface Segregation (depend only on what you need) and Dependency Inversion Principle (depend on abstractions, not on concretions).

Design your methods so that code that uses them can follow these principles.

Why? Because when you follow the ISP you make your needs clear. That keeps your options open about what can fulfill them. Because when you follow DIP changes are less likely to impact you since you depend on stable abstractions not volatile concretions. Which lets you change the concretions with little pain.

I will have to reimplement all the methods in the IQueryable.

If you really need all those methods you can compose yourself of, and delegate to, something that already implements them. It’s a bit of keyboard typing but very flexible.

You should return exactly what using clients need.

If you believe in the solid principles the two worth considering here are Interface Segregation (depend only on what you need) and Dependency Inversion Principle (depend on abstractions, not on concretions).

Design your methods so that code that uses them can follow these principles.

Why? Because when you follow the ISP you make your needs clear. That keeps your options open about what can fulfill them. Because when you follow DIP changes are less likely to impact you since you depend on stable abstractions not volatile concretions. Which lets you change the concretions with little pain.

I will have to reimplement all the methods in the IQueryable.

If you really need all those methods you can compose yourself of, and delegate to, something that already implements them. It’s a bit of keyboard typing but very flexible.

If you don't really need all those methods you can still compose and delegate to something that already implements them. Prune what you expose back to what's really needed. Done this way you can add more as needed and later refactor to squeeze out implementations that are not.