@Lars Kemmann: I might agree about the data portal if it were only a facade, but that's not the case.
The primary purpose of the data portal is to abstract the entire concept of an "application server", thereby providing location transparency. When you call the data portal your code doesn't know if the app is deployed in a 1-, 2-, 3-, or 4-tier environment, and it doesn't need to know or care.
Additionally, the data portal automatically manages a number of common requirements such as impersonation of custom principal/identities from the client, flow of client culture onto the server thread, abstraction of network technologies (Remoting, asmx, WCF, Web API, raw TCP, etc).
It is true that the data portal could have been interface-based. I conciously chose not to go that route because I wanted to support method overloading, thus allowing you to have different read (fetch) method overloads to support different application scenarios.
That said, the current CSLA 4.3 data portal does provide a number of important interfaces necessary for mocking and unit testing scenarios, including at the data portal level. If your primary concern was around mocking and testing you might find that the concern no longer applies in current versions of the framework.
@Kaveh: The idea of domain driven business objects predates the current MVVM concept.
The idea behind a viewmodel is two-fold. First, the assumption is that the model object is in the wrong shape, so the viewmodel needs to expose the properties needed by the view because the model is wrong. Second, the assumption is that there'll be actions specific to the presentation layer that won't (and shouldn't) be implemented by the model.
If you do a good job designing your domain business objects they _will_ be in the right shape. And if you use CSLA then they'll also be fully bindable. So you really don't want or need a viewmodel to reshape the model, because the model is right to start with. Because of this my viewmodels tend to just have a Model property that directly exposes the domain object to the UI.
I do still have a viewmodel though, because the second reason (presentation layer actions) is _extremely_ valid, and I absolutely recommend using viewmodel objects to address this requirement.
CSLA includes a ViewModelBase class (in Csla.Xaml) that helps you create a viewmodel that exposes a Model property and provides protected members to make it easy to implement some common presentation layer actions.