Hmmm. Got challenge this one for the sake of a bit of balance here I'm afraid.
There seem to be 5 charges in Andrew's reply, so I'll try and deal with each in turn:
1) Components are an out-of-date and abandoned design.
The idea of components design pattern existed long before XNA - in essence it is simply a decision to make objects, rather than the over-arching game object, the home of their own Update and Draw behaviour. For objects in its component collection, the game will call these methods (and a couple of others) automatically at the appropriate time - crucially the game object does not itself have to 'know' any of this code. If you wish to re-use your game classes in different games (and thus different Game objects), this de-coupling of objects is still fundementally a good idea. A quick look at the latest (professionally produced) demos of XNA4.0 from the AppHub confirms my impression that Microsoft are still (quite rightly in my view) firmly behind this one.
2) Andrew can't think of more than 2 re-usable game classes.
I can. In fact I can think of loads! I've just checked my current shared lib, and it comprises more than 80 re-usable components and services. To give you a flavour, you could have:
- Game State/Screen Managers
- Drawable primitives
- AI controllers
- Input controllers
- Animation controllers
- Physics & Collision Managers
Any particular game idea will need at least 5-10 things from this set - guaranteed - and they can be fully functional in a completely new game with one line of code.
3) Controlling draw order by the order of explicit draw calls is preferrable to using the component's DrawOrder property.
Well, I basically agree with Andrew on this one. BUT, if you leave all you component's DrawOrder properties as default, you can still explicitly control their draw order by the order in which you add them to the collection. This is really identical in 'visibility' terms to explicit ordering of their manual draw calls.
4) Calling a load of object's Draw methods yourself is more 'lightweight' than having them called by an existing framework method.
Why? Plus, in all but the most trivial of projects your Update logic and Draw code will totally overshadow your method calling in terms of performance hit in any case.
5) Placing your code in one file is preferrable, when debugging, than having it in the individual object's file.
Well, firstly, when I'm debugging in Visual Studio the location of a breakpoint in terms of files on disk is almost invisible these days - the IDE deals with the location without any drama. But also consider for a moment that you have a problem with your Skybox drawing. Is going to the Skybox's Draw method really more onerous than locating the skybox drawing code in the (presumably very lengthy) master draw method in the Game object? Nope, not really - in fact I would argue that it is quite the opposite.
So, in summary - please take a long hard look at Andrew's arguments here. I don't believe they actually give substantive grounds to write entangled game code. The upsides of the decoupled component pattern (used judiciously) are massive.