OO Coding - to use Object Managers or not?

It doesn't feel very "OO" to have all these manager classes manipulating lightweight objects.

I don't know if this is very "OO", but to me it feels very MVC and Separations-of-Concerns-like. Having very lightweight business-classes (to the point they are just data containers) and then repository-objects that move them around is a common pattern.

You can continue to refactor all the functionality out of your User class, but as you said you may end up with nothing left in it. At this point, you could choose to evaluate all the other classes you have created, and then make an individual judgement on each of these classes, deciding on a case by case basis if these classes contain enough functionality to warrant a whole new class.

If you decide that some of these classes are too small, you can then put their functionality back into the User class. I see nothing wrong with having, for instance, a Validate function on the User, rather than having a UserValidation class with only one method on it.

Martin Fowler has some useful views on this.

The fundamental choice is between Service Locator and Dependency Injection. The first point is that both implementations provide the fundamental decoupling that's missing in the naive example - in both cases application code is independent of the concrete implementation of the service interface. The important difference between the two patterns is about how that implementation is provided to the application class. With service locator the application class asks for it explicitly by a message to the locator. With injection there is no explicit request, the service appears in the application class - hence the inversion of control.

Inversion of control is a common feature of frameworks, but it's something that comes at a price. It tends to be hard to understand and leads to problems when you are trying to debug. So on the whole I prefer to avoid it unless I need it. This isn't to say it's a bad thing, just that I think it needs to justify itself over the more straightforward alternative.

It sounds like you at that point where you are moving beyond defining objects as "a dog is-a animal" and moving into object definitions in terms of roles, responsibilities, and behaviors.

I would recommend this book to help you make that transition and really "get it":

Object Design: Roles, Responsibilities, and Collaboration

I don't have an answer to your specific question because it is such a fundamental design decision that you really should learn about the "bigger picture." This book will give you a good foundation in the principles and techniques of Responsibility-Driven Design.