Having just been through a bit of a reindexing nightmare, I urge extreme caution. Non-clustered indexes are a bit of a pain in that they usually not in the same order as inserts. Even with a fairly high cardinality, if your FILL FACTORs aren't set right (most folks have them set at 0 or 100, same-o-same-o), you can cause huge slowdowns of your app just by reindexing. Fragmented indexes became that way because of page splits, which make room in the indexes for INSERTs. Removing that room will cause page splits when new INSERTs occur, which slows down the app, sometimes causing some pretty serious blocking until enough pages have been split.

Before you use any reindexing method, check for the percent of page fullness as well as the fragmentation. That can give you some very good hints as to which indexes need a FILL FACTOR of other than 0/100 and then rebuild the indexes with the correct FILL FACTOR. You also need to consider the average row size in deciding what the FILL FACTOR should be. For example, if a single row takes 7000 bytes, then there's no use in changing the FILL FACTOR. If each row is tiny, then setting a FILL FACTOR of 80% might be serious overkill depending on how many rows are typically added to the table.

Of course, there's a trade off. Decreasing the FILL FACTOR inherently reduces performance of SELECTs because it has to read more pages to read the same number of rows unless the SELECTs are typically single row SELECTs, in which case fragmentation doesn't actually matter. And, of course, you have to consider any batch code you might run on nightly jobs as well as reporting code, all of which just love a nicely defragmented, low free space index.

Keeping stats up to date is a whole 'nuther story and is sometimes more important than defragging especially if you have an ever increasing clustered index.