>Business objects are okay if a design time you know the structure of your data tables and they are not going to change and you bring back teh same structure every time nor be too complex. If you build your queries at runtime and change you number of joins, selected columns, filters etc.. or using updatable views you are better off using datasets.

I disagree. The beauty of business objects is that if you change your backend, your queries don't need to change because they reference the friendly property name, not the backend column name. Business objects allow for complex relationships and adding behavior to the data. And what about an SOA scenario? Do you want to write another layer to convert your datasets into generic lists for use in other non-.net clients? Serializing a dataset for web services becomes a huge object. Business objects are much cleaner and better separated for multi-tier development.

The con is the learning curve and development cost up-front. Writing an app using datasets is quick. I tend to lean towards datasets for smaller, get-out-the-door apps that you don't expect a lot of long-term maintenance on and business objects for the more robust long-term supported enterprise apps.

For dynamic queries, something similar to this:

http://www.15seconds.com/issue/010629.htm

The difference is I am using C# and winforms, and the addcriteria is populated with friendly business object names, not column names and the actual query is generated in another layer (after going through a mapper class that links the friendly business name with the column name).

I just found by searching that there are lots of examples addsearchcriteria, addcriteria, etc... out there. I think the hibernate criteria api may be similar too.