Having just a SQLDataSource is perfectly valid, if it's just a demo, a prototype, or a quick hack. It's fast, it's easy, it just works and gives you the results you need.
However, when an app is designed and built for the long run, and anticipates that things (requirements, customer wishes, eventually the database schema) may change, then it might make a whole lot more sense to introduce a proper "business" layer - model your business objects as objects, and then provide a mapping from the underlying database to those business objects.
As the saying goes - you can solve pretty much anything in computer science by one more layer of indirection (or abstraction) - same holds here.
SURE: you can go straight to the database, and sure, at first and for the first iteration, that's possibly (or probably) the quickest way. But in the long run, when an app is built to last, it's usually a quick-and-dirty way - the cost of upkeep, the cost of maintenance, the cost and effort needed for changing according to your and your customer's needs will grow and quite quickly, that quick'n'dirty solution doesn't look so great anymore, in terms of effort.
So to sum up my point: yes, initially, using a direct SQL Data source might be quicker and easier - so use it when that's the important point: to get things done for a quick demo, a proof-of-concept style app. But in the long run, when you look at the life span of an app, it's usually worthwhile investing a bit more (design and coding) effort to add this layer of abstraction so that your web pages don't directly depend on the details of the database underneath.
Marc
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
