Client server pub sub Architecture using Composite WPF

Jul 5, 2008 at 1:21 PM

I see the value in using prism( Composite WPF.. I really liked the name prism) but don't know why they changed it.. anyways). But I am  not sure how it will handle client server communication (where the view and presenter is in exe and model is in exe or dll  on another machine , model will  be a layer between view and database.) using publisher subscriber model(Where the database changes will automatically change the chart on the front end and changes to chart values will update database) 
1>Will Prism be able to handle databinding where the binding object is on another server?
2> Everybody talks about MVP or MVVM but has anybody tried "Martin Fowler's Way of MVC? What are the advantages and disadvantages of using MVVM vs MVP vs MVC using prism?
3> Can I implement publisher subscriber using COMPOSITE WPF and WCF? ( A simple example  of  two way binding and updating  two way data thru. MVP/MVVM/MVC would be wonderful!!)
4> Can the windows developed using composite Ui be  be floated  and dragged and dropped  based on some kind of sort mechanism?
5> Where do you draw the line between 100% wpf data binding in XAML vs code to use databinding?

I am trying to convert MVP RI into client server application where Server exe will provide data to client exe and view and database will be updated automatically. 

ANY discussion,  code samples(c# will be obviously language of choice) will be greatly appreciated.

I am planning to start a discussion about more articles, integration of composite WPF with WCF, middle layer third party software (spring.net etc) and of course WF
Happy vacation
Shan
Jul 8, 2008 at 4:58 PM

1>Will Prism be able to handle databinding where the binding object is on another server?

Composite WPF doesn't add anything to WPF with regards to databinding. However, WPF does have great support for 2 way databinding. If the object you are binding to has a way of notifying WPF that something has changed (IE through the INotifyPropertyChanged event) then your view will reflect changes made in the object and vice versa. Then you have to find a way to immediately persist the changes to the model in the database and also change the model if something changes in the database. There are lots of ways to do this, to many to mention here.  

2> Everybody talks about MVP or MVVM but has anybody tried "Martin Fowler's Way of MVC? What are the advantages and disadvantages of using MVVM vs MVP vs MVC using prism?
I hope I'm not stirring up a patterns debate here. I usually place martin fowlers MVC pattern in a historical perspective. In the good old days, before the nice GUI's of today, a program had to draw it's own UI. That means drawing the textboxes, the windows, the buttons, everything manually. Then also, you'd have to interact with the input from the user (keypresses, mouseclicks if they had them in that era, etc..). That took a lot of code, so it made sense to split up the presentation logic (drawing of stuff) from the interaction stuff (handling of the UI input) and also the data. I think that's where fowlers MVC pattern originated from. (Again, this is my personal interpretation).

In these modern times, the level of abstraction is raised considerably. Controls encapsulate a lot of the difficulties that the original MVC pattern tried to solve. That beying said it's still a good idea to seperate the presentation from the logic and the data. Nowadays when people talk about MVC they usually mean this seperation of concerns, rather than strictly following fowlers pattern. The way to implement this seperation of concerns using a bit more modern technologies (like windows forms) would be to use one of the MVP variants (supervising controller or passive view). In passive view, the view is really just a dumb displayer of data, and the presenter is the one who decides which fields to display with what data. In Supervising controller, the presenter only passes around a model to the view and lets the view take care of basic databinding.

Then if you look at WPF, it has really powerful databinding capabilities. And because it's so powerful, the need to seperate out a model (what you are binding) and the logic (interaction) becomes less. That's where the presentationmodel or viewmodel comes in. Check out the Presenter model here: http://msdn.microsoft.com/en-us/library/cc707885.aspx

3> Can I implement publisher subscriber using COMPOSITE WPF and WCF? ( A simple example  of  two way binding and updating  two way data thru. MVP/MVVM/MVC would be wonderful!!)

I'll try to whip up an example soon. I'll post it on my blog (blogs.msdn.com/erwinvandervalk) when I'm done. I'll keep you posted

4> Can the windows developed using composite Ui be  be floated  and dragged and dropped  based on some kind of sort mechanism?

Sure, but again, Composite WPF doesn't add anything special here. If you can create a floating and dragable itemscontrol in WPF (and I know that's possible, just search for drag & drop functionality in WPF on the web for examples), you can use CAL to load views into it.

5> Where do you draw the line between 100% wpf data binding in XAML vs code to use databinding?
This is a touch question and it probably depends on your taste. The more you do in code (and the more you tend towards the passive view pattern) the more you can unittest your application. However, you're also writing a lot more code. My personal opinion is to use WPF databinding as much as possible. To do that, I would try to create a Presentation model that is easily bindable.

Hope that helps.

- Erwin
Jul 9, 2008 at 10:49 AM
Just to add my 5 cents, and it's just my take.

I think that we should be looking at Composite WPF as one tool for creating rich modular and composable applications instead of an answer to the whole problem. WPF is a great environment and a leap forward from Windows Forms to enable us greater flexibility in the way we create windows applications. The way I see it, Composite WPF solves the problem of modularity and parts of UI Composition, but it doesn't solve all problems, and nor should it.

WPF alone can solve a lot of the problems where composition is a concern, since we can stick almost any object into the UI and have a DataTemplate render it for us, that's one form of allowing UI composition. So you really can use any pattern that works for you, that's what I love about C/WPF, it's not binding us to patterns like SCSF did, it's now easy to break free from the pattern chains and take what works for you.

I think what I am feeling the most is we need to first see great examples of what strategies we can use to try and solve a lot of the concerns we all have, in many ways I think the whole issue of WPF applications is actually broader than C/WPF itself, this is something I'm learning more each day. At first I though that C/WPF was going to be the silver bullet.

Okay, enough rambling :)
-Brett




Nov 16, 2009 at 6:54 AM
Edited Mar 23, 2010 at 9:50 AM

Last week was my first presentation while playing the Solution Architect Role in ArabiaGIS, so I tried to start with an introduction to design patterns, and my first subject was the Model-View-ViewModel design pattern. in the presentation I tried to introduce the design pattern concept, showing its importance and the goals off applying it.

The presentation will focus on the history and the importance of MVVM and then go into the detailed of this important design pattern for architecting a WPF application.

 To see the presentation: http://www.jaftalks.com/Home/Show/%20MVVM%20%E2%80%93%20Model%20View%20ViewModel