I feel that a CSLA business object is nothing than a view model in the MVVM design pattern.
If anyone know about this pattern, please let me know if you have the same idea like me:
CSLA objects support data binding, they conatins the undo command (and I don't know yet what to to about the redo command, please rocky, help me !), they also encapsulate a specific use case (a user interface encapsulate a use case, so I have this idea...).
although I am not sure about the Save command, if there is a method to change it's behavior when the object is in the presentation layer( in this case the save command will save the settings of the user) or in the server layer (where it will save the data...)
The VMVM patter is also named the model-view-presentation model and it is very popular in the WPF world.
my idea is that a CSLA business object can play the role of the presentation model when it is in the presentation layer, and the role of a business object when it is in the data access layer...
any one can share me this concept ? (I am using the Prism framework)
You are correct that the Model-View-Controller (MVC), Model-View-Presenter (MVP) and Model-View-ViewModel (MVVM) patterns are very close to each other with slight differences in how they manage application behavior. In all cases, the one consistent element is the Model, which is where I would categorize your CSLA business objects. BO's aren't as concerned with how they are presented to the user but I can see how you would come to the conclusion you have. Here is a scenario I use when discussing this subject with other developers here:
Because most explanations of these patterns put so much intelligence into the middle piece (the Presenter, Controller or ViewModel), it is easy to assert that the BO is actually a part of this layer. I don't necessarily disagree with that assessment, but I will counter that given a little more thought, you'll see that there is still another piece of code sitting between your UI and you BO - something that relays, or maps, the user's actions to methods on your BO. Whether it is a code-behind page or a command object or whatever, something handles the mouse click or keystroke by the user and passes it along to the BO.
The final test, in my mind is the fact that the BO doesn't care how it is presented. It can be shown in a web app, Windows app, WPF or exposed as part of a service - or not shown at all. Furthermore, within a web app, for instance, the BO doesn't care if it is shown in a GridView, ListView, FormView, DetailsView or rendered with good ol' fashioned markup.
HTH
I tend to look at it the way Paul describes.
CSLA objects should be thought of as the model in any of these patterns. If your object is UI specific, you did it wrong.
Views are obviously very UI specific.
Controllers are (in reality) UI specific. Yes, I know the theory that they are independent of specific UIs, but in the real world that's not what happens. Controllers make assumptions about specific UI models (stateless, stateful, event driven, postback driven, etc). You have to consider that you'll write different controllers for each type of UI you create.
Similarly, a ModelView is UI specific. And use case specific. I'm not a real big fan of the MV idea, because the MV sits on the border beween the interface and business layers, and could easily end up containing both UI and business logic. And that'd break clear layering in the area where layering is (by far) the most important.
If you look at what I've done with CSLA .NET in WPF (and now Silverlight) you'll see that I treat the data provider control as an "MV". But one that is not use case specific, thus eliminating the temptation to put business logic into that location - because all business logic must be in the model.
So the CslaDataProvider supports commanding - but only commands understood by all business objects. And in Silverlight we invented our own replacement for commanding (because Silverlight doesn't have it) that does essentailly the same thing.
You could do the same thing with an MV pattern - using that instead of a data provider. The real trick is to decide whether the MV is part of the UI or business layers, and ensure it only has logic for one or the other. As soon as you have an object that contains UI code and business code, then all you've done is come up with a more complex way to write VB3 code.
Rocky you say:
"So the CslaDataProvider supports commanding - but only commands understood by all business objects"
Consider your implementation of the "AssignButton" button on the ProjectEdit.xaml page. It has a classic link to a "Click" event handler, with code in the CodeBehind file. But if I'd like to use a CommandBinding here instead, I understand that I would need some ViewModel object hosting the ICommand implementation.
Does this imply that if we want to use commanding for other kinds of business logic-based commands (other than those "commands understood by all business objects") we would probably have to use something like a ViewModel as opposed to the CslaDataProvider? It seems like that would be the way to go?
That is certainly one approach, yes.
MVVM, like all patterns, has consequences. (read the GoF book for good background on this)
Consequences are good and bad. Every pattern has some of each.
MVVM is a very immature, but trendy, pattern. As such, its consequences are not yet fully understood, and there are many variations on the pattern out there. Anyone claiming to be using the one true pattern is full of something foul.
With all that said, it is clear that the data provider pattern is a pre-cursor to MVVM. Microsoft developed the data provider scheme before the MVVM pattern was coined.
As always, my philosophy is to leverage what Microsoft gives us, leaning toward RAD development whenever possible. So I enhanced the data provider model in WPF to support more actions than just "read data". And I think that's really nice, but the WPF data provider model makes it hard to extend this concept through subclassing or similar schemes.
The MVVM technique means so many things to different people, that it is hard to talk about. I suspect it will fragment into many sub-patterns, hopefully each with a different name, so it is at least possible to have a meaningful converstion.
I vew MVVM as a case where the "VM" is very much like a data provider, in that it is a UI object that implements actions. One action implemented by all VM objects is to "get the model" and expose the model as a property so the View can bind to the Model.
I have some thoughts on a way to allow you to subclass the command manager. But I'm not sure I want to go that way until I understand whether the MVVM pattern will actually affect how Visual Studio's designer works. So I'm in a holding pattern until we see another CTP of VS 10 - otherwise it is too likely I'd waste all of our time by doing something not directly supported by VS.
I do know that the CslaDataProvider implementation (with InvokeMethod) in Silverlight is a lot more flexible and powerful (in some ways) than the WPF implementation. This is because SL has no data provider model to start with, and so we created something very similar, but also something that is easier to extend. Accidentally, the result is something that fits better into the MVVM pattern than the WPF model.
But again, I'm just waiting for another VS 10 build to see where they go with XAML designer support, because I'm very hopeful that VS 10 will have a really good designer that enables RAD development, and I want to make darn sure that CSLA objects work nicely in such an environment.
Copyright (c) Marimer LLC