Your UI layer should be far-removed from your data access strategy - it shouldn t be dealing with raw data. Thus, your UI should communicate solely with your domain objects (directly or through a service layer).

You can then have the UI layer create the data structures that it needs in order to render. Any performance concerns could be mitigated through a caching strategy.

This affects the readability, testability and maintainability of the code which should always be long- and short-term goals of any design.

I think ideally you d want to see something along these lines:

 UI
 /|
  |
SERVICE (? depending on the design)
 /|
  |
DOMAIN
 /|
  |
 DCO
 /|
  |
 DAL

EDIT:

On the flip-side, if you re building a very straight-forward WebForms application, then you may be able to forgo some of this complexity and just use the designers provided by Visual Studio. I ve found, however, that applications often evolve beyond the capabilities of the drag-and-drop interface and you end up having to refactor into a more separated design.

You always need to know what you stand to gain/lose by choosing an architectural strategy. If you can live (on the edge) with no testing, reduced readability and tighter coupling of the UI to the data ****shudder****, then perhaps the more straight-forward approach is for you.

Some links for further reading

• SOLID principles of OOD
• Fowler s PoEE
• MSDN: Patterns and Practices

I don t know about performance, but in terms of maintenance and readabilty the use of a list<> is far better.

One large problem with using datasets with data tables is that the next guy to work on the code will have a big problem figuring out what tables are in a given dataset - especially when you consider the habit a lot of people seem to have of creating new tables and adding them to the set for use later.

With a list of objects it is strongly typed and explicit, moreover the structure of the object is well known and will references to properties will change with the object. Often with datatables people will resort to referencing columns by index rather than name which is a timebomb.

If performance is an issue then look at other generic collections, things like dictionary have very very nice key retrieval properties (almost n(1) apparently) which can make a huge impact in the right spots.

Obviously this sits on top of a discussion about interfaces and am assuming that you know how you want to expose your objects functionality.

Using a List<T>, IList<T> or even better an IQueryable<T> give you the advantage of hiding the implementation details behind an interface boundary. This frees you up to change how you handling the retrieval of that at a later time.

i would say it would be better to use your custom objects instead of a dataset. it is best practice to have your ui/business layers be blind to how you are implementing your data access. Any way you actually talk to your data source (db, xml, ect.) should be contained in your data access layer and your business layer should just be expecting your custom objects.

Check out Performance Comparison: Data Access Techniques. It is quite old but has some good information regarding the performance between DataSet, DataRader, and XmlReader.

List<T> is type-safe - You always know what you re getting and you never (rarely) have to worry about casting. You don t have that luxury with DataSet.

List<T> also has all the nice Linq helper methods built in, assuming you re on 3.0

I would suggest a List<> if you are just reading from the db and presenting on the UI. The DataSet is a pretty complex and heavy class, so I would use it only of you needs its special features, like deferred updates, data relationships, etc.

If you are worried about performance, take a look at the code-behind of a strongly typed dataset and you can make up your mind yourself ;)