to View:

1. Domain Model Class - easy, little change to the application, but, tightly coupled and the Model may be polluted with craft to support UI needs; This pattern can be preferred when the screen design doesn't need any special UI support (may pollute the Model) for our custom data binding solution.
2. Presentation Model - wrap of the real domain Model. Then View will binding to Presentation Model directly.    the data  shape for business and UI may quite different    one example: the real domain are an aggregate structure and your view definitely needs some INotifyPropertyChanged - type too. In this particular case a Presentation Model probably provides a flattened view of the domain aggregate to make data binding smoother
   
3. Data Transfer Object - just a lump of data, not behavior.
4. DataSet/DataTable/DataView - especially datacentric UI, sometimes it's the easy way to solve the problem, but,  you can't embed any real logic into the dataset, and it will make duplication of logic (you can centralize the related business logic for the dataset).