I do not know if your question is about dictionary attacks in general, or dictionary attacks in the case of a WiFi network with password protection.
For the general question of dictionary attacks: there are two kinds of dictionary attacks, the online attacks and the offline attacks. An offline attack is one such that the attacker got enough data to "test" passwords on his own machines, at a rate which is limited only by whatever computational power he can muster. For instance, the attacker got a copy of the hash of a password. On the other hand, an online attack is one where the attacker must interact with an "honest" system (one which knows the correct password, e.g. a target server, or the client itself) for each guess.
A password "strength" can be measured by its entropy, which is a way of stating how many values that password could have assumed. For instance, a password with "25 bits of entropy" is such that it has been chosen randomly (and uniformly) among a list of 225 possible passwords. The notion of entropy can be refined a bit in case the password selection process is not uniform: we say that a password has n bits of entropy if an attacker trying a list of potential passwords, in decreasing order of probability (i.e. beginning by the most frequently chosen passwords), will hit the right password after an average of 2n-1 trials. Depending on your user base, you might have a bit of success at educating your users into choosing strong passwords, but it is not realistic to expect more than, say, about 32 bits of entropy (if you enforce too strong password selection rules, users will actively work against you, e.g. by writing passwords on stick-up notes or sharing passwords with other sites or other users).
The first mitigation in the presence of offline attacks is to use a salt: the idea is to "tweak" the password-verification data that the attacker can know with a publicly known value (the "salt"), which is different for each password. This will not hinder an attacker bent on breaking a single password, but it will prevent cost sharing: if the attacker wants to break 10 passwords, it should cost him 10 times the cost of breaking one. Precomputed tables, in particular the much hyped rainbow tables, are a specific case of cost sharing. A good salt is chosen randomly and uniformly with a good random generator, and stored along with the password hash.
The second mitigation is to make password derivation expensive: you do not hash once, you hash ten thousand times. This makes normal password usage (for verification) 10000 times slower (but this can often be tolerated: we are talking about 10ms instead of 1µs) but also multiplies the work factor for the attacker by 10000 (which turns, say, a one-minute attack into a one-week attack). Security is then achieved if 2n-1 > p*s where n is the password entropy, p is the ratio between the attacker's and the user's patience (e.g. if the attacker is ready to invest one week of effort and the user cannot wait for more than one second, the ratio is 7*86400 = 604800), and s is the ratio between the attacker's computing power and the normal system power (e.g. the attacker has 20 PC with big GPGPU, and the normal system is a smartphone: this brings s in the range of 500 or 1000).
Bcrypt is the oft-recommended password hashing method, which combines a salt and a configurable number of iterations.
A more thorough solution is to avoid offline dictionary attacks: you should not let an attacker get hold of any data which allows him to perform such an attack. In a Web/Internet context, this means that, for instance, you will perform authentication within a SSL/TLS tunnel (something known as "HTTPS"). You would still want to do good password hashing for password storage on the server, in case the attacker gains a read-only access to your database. Another kind of protocol is Password Authenticated Key Exchange: a cryptographic protocol which results in a shared key (suitable for subsequent symmetric encryption of data), with mutual authentication of client and server relatively to a password; this protocol can be played in full view of the attacker and it is still inherently resistant to offline dictionary attacks. The most recommended PAKE protocol is SRP.
If you can force the attacker to play things online, then you can thwart him by enforcing arbitrary limitations in the number of requests he may submit. The most extreme case is what smartcards do: after three wrong PIN, the card commits suicide. Weaker rules (e.g. refusing to process more than 10 guesses per minute) will already dispel most attackers.
About WiFi: there are several authentication protocols which can be used in WiFi. In WEP and "WPA-Personal" systems, authentication is called "PSK" (pre-shared key): encryption and integrity checks will be performed with keys derived deterministically from the WiFi password. This gives plenty of data for an attacker who wishes to perform an offline dictionary attacks. Since the key derivation protocol does not include provisions for a high number of hashing iterations (after all, it must be implementable with 30$ home routers), dictionary attacks tend to be quite effective. So the only real defense here is to select big fat random passwords, so that the entropy is high.
With "WPA-Enterprise", authentication is done through a generic layer called EAP, which encapsulates messages for an underlying protocol; the base station is supposed to forward those messages to a RADIUS server. There are many authentication protocols which are then applicable, some of which being of the PSK persuasion; but others are arguably stronger. For instance, there is an EAP-EKE, which is a PAKE protocol, hence resilient to offline dictionary attacks; another one is EAP-TLS, which internally performs a full SSL/TLS handshake, and thus, potentially, may use SRP-with-TLS.
Thus, with WPA-Enterprise, you may use authentication protocols which tolerate passwords with relatively low entropy, but this depends on what the client and the base station will support.
A word to the wise: I only talk about the use of passwords in WiFi authentication. I do not claim that once authentication has been performed, the WiFi link is adequately secured. It is best to treat a WiFi link as an Internet-like link, subject to eavesdropping; the main goal of the authentication protocol is to deter attackers who want a free Internet access.