I'm updating my answer because a lot of things weren't clear before the comments. Please bare with me while I explain my thoughts.
In general, two key aspects to consider in any design is cohesion and coupling. We all know that we need high cohesion and low coupling to be able to make a more reusable and extensible design.
So, if the world has to manage everything, that means that it has low cohesion and tight coupling (because it needs to know and do everything). However, this is also the case when a game entity has to do everything. Update his location, render his texture, etc. etc.
What you are really interested in is to create systems that focus on one aspect of the entity. For example, a game entity could have a Texture, but a Renderer would be responsible to render that texture on screen. The Renderer doesn't care what other properties the entity has.
Taking it a little further, a game entity is simply a bag of properties. These properties are manipulated by systems that are focused on specific properties. And this is where Component-based Entity Systems (CBES) come in, where properties = components.
Specifically, CBES with Systems (or SubSystems). This design tends to have a few Systems that are focused on specific components of an entity while not caring about what other components the entity has. Also, the Systems are coupled only with the information they need to process these components.
Let's take your example. Since the input of where to move the entity is based on the player's controller, you would probably have a PlayerControllerSystem. This system, would control, apart from many other things, the entity's PositionComponent. In this case, the PlayerControllerSystem would need to know about the Level and the PositionComponent. If later on you decide to add collision detection, you would create a CollisionSystem that would again use the position of the entities, but this time to calculate bounding boxes (or you could have a BoundingBoxComponent, your call). The fact is, you can easily switch on or off behavior (even on the fly) by simply adding/removing components. So, more behavior means more systems are manipulating the components of an entity, but they are all in a well defined class with low coupling. Want scripting? Add a ScriptComponent. BAM! You just added scripting capabilities with 2 classes. Physics? Sound? Same again.
So, the reason I am advocating CBES with SubSystems is that it is perfectly OO and an overall easy maintainable/extensible system. Adding a behavior to an entity is as simple as deciding what data that behavior needs and which entities need it.
For more information about Component-based Entity Systems with SubSystems, there is an excellent series of blog posts by T=Machine at Entity Systems are the future of MMOG development. The author even went as far as creating a wiki for collecting various implementations named Entity Systems Project
A general (and well-known) post about Component-based Entity Systems in general is the Evolve your hierarchy who created the system for Tony Hawk Pro.
Finally, if you are looking for a library with example code, don't go any further than the Artemis library. Artemis is primarily in Java but here is a port in C# (which I am currently using in my XNA project).