MVC: Lean controller vs injecting the repository?

The controller should ideally be free from domain logic right?

How does that match up with injecting a repository class into it like in nerd dinner?

If you are one of those who don't inject the repo into the controller, how d开发者_开发百科o you name your app/domain layer classes that contains the code that references the repository accessors and does the work with the model classes? Or do you split it up further? How?

Added to the question:

For the above question, could you please consider theese three scenarios:

1. Retrieving a model and returning a view
2. Recieving a form edit to validate and persist to a database
3. Order processing

I hope this addition can make the question clearer such that we can refer to common types of scenarios.

---

We inject the repository interfaces into our controllers, so our controller doesn't care about domain logic implementation. Our IoC container takes care of determining which class to use as an implementation for each repository interface.

---

Data Access Logic != Domain Logic

Injecting a controller with a Repository is fine if you are trying to do DDD.

I name things ElephantRepository, ElephantService or ElephantQuery depending on the pattern I'm using at the moment.

---

I would be really interested to see an MVC application that didn't access a repository/service/dal layer from the controller. ;)