What am I missing with table adapters?

An excellent question to reply to tons of literature and zillions of words about architecture, middle-tier, design, DAL, LINQ and so on.

If I use TableAdapters, apart from the pretty ORM diagram in LINQ, what am I missing?
 

The short answer is that functionally speaking, you miss just nothing  :-) If it works for you, that's OK.

A more articulated answer entails one brings on the architectural perspective of things. So architecturally speaking, the pattern behind table adapters is a Table Data Gateway with a vision of the data model that is along the guidelines of the Table Module pattern. In a nutshell, everything is a table; you model your actions through the schema of database tables and you use a gateway object to centralize your data access code--ADO.NET or perhaps Linq-to-SQL stuff.

Where do you start missing something? As the complexity grows beyond a certain threshold. If you never reach that threshould, you're just fine.

There's a nice figure in the Martin Fowler's book "Patterns of Enterprise Application Architecture" that shows how Table Module is a pattern with a relatively low initialization cost. These costs describe a function that runs pretty soon into an asymptote--a sort of vertical wall that it attempts to overcome making costs go high with the complexity of the domain. A domain-based model--like the one that more or less you can see through Linq-to-SQL, has a more linear curve, with higher initialization costs but a regular growth with the complexity of the domain to design and implement.