Since they follow the same use case, the objects should already be the right shape. On the other hand, if you use responsibility-driven design for your business objects, your object model should naturally follow the shape of the use case, as should the UI. And I agree that if your Model was not designed using good OOD (is data-centric rather than respnsibility-driven) then your VM will probably have to do that - which is really lame, and simply means you did a crappy job with your object model. I've had people argue that the point of the VM is to "reshape" the Model for the UI. In either case (anemic or rich Model), if your object graph is complex (parent-child-grandchild-etc) your VM can become incredibly complex very rapidly, as you try to flatten or duplicate the shape of the Model. Your VM could have to implement and delegate (bi-directionally) all the data binding interfaces, authorization, business rule and other functionality that is built directly into CSLA. On the other hand, if you use one of the "anemic model" variants of MVVM with CSLA objects, you'll have to do more work in your VM or sacrifice a lot of functionality. That type of MVVM implementation works really well with CSLA. Fortunately there are variants of MVVM where the VM exposes the Model as a property, along with various methods (commands) that can be bound to buttons, etc. In fact, it is incredible rich, with the DataTable being the only thing I know of that comes close. NET ensures that your Model is far from anemic. Those variants require that you do a lot of work in the VM to overcome the lack of functionality in the Model, and that's fine. Many of the MVVM pattern variants assume an anemic Model, such as a bunch of DTO/proxy/entity objects you get back from calling a service or something like EF or L2S. The question is which MVVM pattern? There are several variants with different pre-conditions and consequences. IMHO if you are using WPF then you make your life easier (in the long run) by following the MVVM pattern. Here is the XAML code I ultimately used for the treeview: So basically you just refer to the "Modules" collection property in User for your binding path. The second part of my question first - I figured this out after rereading that part of the book, the collection is exposed through it's parent class - so in this case I had a "User" class and the "Modules" class is exposed through user as a child collection. So, to answer my own question just in case someone wonders across this. I'm hoping the solution to that is in the article you suggested. I will check out the article you suggested - I have noticed that every time I refresh the datasource the treeview collapses back to the root level objects instead of staying expanded where the user changed something. I did finally get this figured out, at least it displays and binds. Kevnworking replied on Tuesday, JSorry for the late reply. Second, and this is somewhat related to the first part, when needing to access a collection of child objects in a root parent object do you have to create another CslaDataProvider for that collection or is there some way to bind (in XAML) the child collection from the parents data provider? I looked in the book but couldn't find the answer - perhaps my brain is fried from working all day. I was hoping that the one line above would give me something to build on. I could be way off on this - I'm new to WPF (obviously) but have found it quite easy to databind textboxes, labels and datepickers to my objects in XAML. I would think it would be fairly easy, something like: First, can someone turn me on to an example of databinding a child collection of objects to a TreeView control? I've been wrestling with this for a few hours now and I can't figure it out - I THINK I'm doing it correctly but I get a big bag of nothing on the form.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |