In an WP app which approach is better.
From the .xaml page, call a method of another class (pass the delegate of a .xaml.cs callback Method ) which makes some request to server , receives data and when requests complete calls the .xaml.cs page method. and in call back method we get data and bind the data with a control (ListBox).
Bind the List box with an ObservableCollection object of MainViewModel class. and change the bounded object from the MainViewModel. All the calls to requests to server are made in MainViewModel class.
I vote for the option 2. Event the project templates (Eg. Databound application template for Windows Phone 7) gives you the MainViewModel and binds a Listbox to an ObservableCollection in that class.
The MVVC approach gives you a lot more flexibility, your UI is totally separated from the logic. ALl your UI needs to know is that it is bound to an ObservableCollection and it doesn't need to know how that collection is filled.
I think you should use the second approach which allows you to create loosely-coupled applications. The big advantages of such applications are:
separation of concerns: different subsystems/layers are independent
unit testing is simple
refactoring is easier
increase ability to code reuse
...
Regarding WP7, you can read my article which shows how to code using this approach:
a framework for building of WP7 application
Related
I am involved in the development of a WPF Prism application which uses the event aggregator to send global type messages which are then picked up by the shell. For example, a viewmodel might want a toast message displayed but doesn't really care how it is displayed. In this instance the shell would be setup to process those events and act on them application wide.
The question I have is how do you do it if a particular view wants to display the toast messages differently. I like the global approach because it is very simple, but how to customize it for special cases?
I think this really depends upon how your application is setup and what standards/patterns you are using. In MVVM I see two approaches.
View-First
If your View-Model is injected into your view, then send the messages to your view, and let the View decide what to do with it. If it wants to display them itself, it can do that. If it wants to send them to your shell, it can do that through the event aggregator or injecting a Toast service interface. That keeps your View in control of the visual.
View-Model-First
If your View is injected into your View-Model, then your View Model should be asking for a different View, which should be bound to its own View Model. If it wants to send messages to another View-Model, it can do that through the event aggregator or injecting a Toast View-Model/service interface. That keeps your View-Model in control of the navigation between Views.
I prefer the View-First approach because it keeps your View in control of the visualization of your model. But I'm very interested in how other MVVM developers tackle this. This seems very closely aligned with the question of how to present dialogs in the MVVM View-First approach.
Using Eventaggregator for this purpose is not the right way I think, because the events are broadcasted to the entire application.
One possible way to handle the scenario is your viewmodels can get an IMessenger interface injected in the constructor. There is an application implementation of IMessenger(which is injected by default) and you can have customised implementations of IMessenger according to your needs. Your viewmodel just calls an interface function(say DisplayMessage()), but according to the Messenger injected to it, the behaviour is different.
I am trying to find the way to build complex web pages with MVC3 and AJAX.
I would like to use components to achieve this.
Each component is consisted of it's own model, view and controller.
Multiple components are then placed on some complex view and should act together to
provide desired behaviors.
In some situations, when user performs some action (interaction) with one of the components,
I must update other portions of the page via AJAX.
Component on which action (interaction) occurred, in it's implementation, does not assume anything about view on which it will be used and what portions of the pages should be updated and how.
So when some interaction occurs in some component, I need a mechanism (outside component itself) which will handle this situation and update appropriate parts of the page.
How would you, generally, implement such mechanism?
I would use the Mediator Pattern, also sometimes mistakenly referred to as the manager pattern.
This class would mediate the communication of your components.
I've written 1 WPF app. A pretty simple app. It works great and is being used heavily as a LOB app today. Now I'm going to start work on a major re-write of an old VB6 app, and will make it into a WPF app as well. When working on the first app I learned of the INotifyPropertyChanged interface, and how vital it is to WPF/Silverlight data binding. My concern, now, is that quite some time ago I wrote a WCF service which is meant to replace the old middle-tier component I wrote in VB6 many years ago, for the old VB6 app. The WCF service I wrote returns ADO.NET datasets, because honestly I've been working with those for years and am comfortable with them. However, now that I'm beginning to work on this new app, I'm very concerned about my WCF service, since ADO.NET datasets don't implement the INotifyPropertyChanged interface.
So I've started looking at other things. Right now I'm looking at Entity Framework. I'm using Julia Lerman's book, "Programming Entity Framework: Second Edition", and it really looks promising. I've working through her example of a WPF app, which uses a EDM assembly she wrote in a previous chapter. Including references to the assemblies gives me CollectionViewSource's, and at least to me, it appears as though they act much the same way that the INotifyPropertyChanged interface does.
So my question is this: does the CollectionViewSource class implement the INotifyPropertyChanged interface? I've tried looking at the MSDN documentation, and it doesn't say so, directly, but I'm wondering if the DependencyObject class CollectionViewSource inherits from either duplicates the same functionality as the INotifyPropertyChanged interface, or does CollectionViewSource implement it?
You'll notice the MSDN doc on CollectionViewSource contains this as the class declaration:
Public Class CollectionViewSource _
Inherits DependencyObject _
Implements ISupportInitialize, IWeakEventListener
Neither it nor its base classes implement INotifyPropertyChanged. When you bind to the View of the CollectionViewSource, you must call its Refresh() method yourself when the underlying collection changes. If you change properties (such as sorting and grouping) of the CVS, Refresh is called automatically.
just to mention a little detail to Rod answer:
when adding or removing an item to collection, the items goes through any filter, grouping, sorting, etc.
But when a property of an existing item changes, then, you have to handle that by yourself to update filters, grouping, etc.
At this point, the solution of the Refresh() works BUT, can bring very bad user's experience since the whole collection get refreshed.
One solution is to simulate an remove/insert of the item. See my post fore more details.
I am new to GWT and getting back to programming after long gap...my question is about MVP implementation in GWT, I have gone through the following post and they were quite helpfull, but i still have some doubts
What are MVP and MVC and what is the difference?
What's your recommendation for architecting GWT applications? MVC, MVP or custom messaging solution?
i think the GWT tutorial (http://code.google.com/webtoolkit/articles/mvp-architecture.html) of MVP also has contoller (AppController ) in place and some of the responses are managed at Contoller level not at presenter. So my question is what should be the role of Controller in MVP pattern implementation?
From where should we initiate the async server call, presenter or controller , say if i have to save the record should i call the server function (which calls the DAO and saves the record) from Presenter or should presenter post event using event bus and conroller act on the event and calls server function for saving.
The GWT tutorial page you linked to says about the AppController:
To handle logic that is not specific
to any presenter and instead resides
at the application layer, we'll
introduce the AppController component.
So it's the glue between multiple Presenters, Views and the Model (maybe multiple Models). It also handles the browser history. And maybe additional things that aren't specific to one presenter.
As for the server call: There are several options, but I personally wouldn't do it from the view, and also not from the presenter - I'd use a model listener. The reason is, that multiple views and presenters can work together on one model. And when they change the model, that change should be sent to the server. Maybe you don't want to do that immediately, but collect a few changes before you send them. In that case, you could have a timer that's set up - well - by the AppController.
Answering to your last paragraph, I would say you should do it in presenter if there is something (some button) on view that is supposed to do it. Presenter is logically strongly tied to view (technically it should be weakly tied, by interfaces only not by implementations). If you want to save the record on some action which is not explicitly called from view, I wouldn't do it in presenter.
What are some lesser known tips for implementing a loosely-coupled MVC structure in a non-trivial desktop application (e.g. having at least two levels of views/controllers and more than one model)?
Use interfaces.
A lot. I like using the "IDoThisForYou" style (even in a language where this isn't idiomatic) because an interface represents a role that another class can use.
Make the controllers responsible for controlling interaction
The controllers control interaction between domain objects, services, etc.
Use events to pass information between controllers
Let every controller who needs information subscribe to the event. Use an interface.
Don't put presentation information on your domain objects
Instead, allow the controller to create a presenter or view model which has the information you need. This includes no "ToString()". If you're in a language without multiple inheritance you might end up with a bit of duplication between presenters. That's OK - duplication is better than coupling, and the UI changes a lot anyway.
Don't put logic in your gui
Instead, allow the controller to create a presenter or view mdoel which has the information you need. This includes train wrecks like "MyAnimal.Species.Name" - make it present "SpeciesName" instead.
Test it
Manually. There is no substitute. Unit and acceptance testing goes a long way, but there's nothing like bringing the app up and actually using the mess you wrote for finding out how messy it is. Don't pass it to the QAs without having a go yourself.
Oh, and don't mock out domain objects in unit tests. It's not worth it. Use a builder.
Declare event handlers in your interfaces (important for the views). This way you can loosely couple event handling which is managed by the controller. You may need to use the InvokeRequired when working with the view if your application is multi-threaded.