I am tasked with implementing a simple confirmation dialog for trying to close the main window of my application, but only while a specific process is running. Closing the application means aborting that process. If that process is not running no confirmation is needed.
At first I just created an interface to get Application.Current.MainWindow and used the Closing event of that, but my teacher came up with something else, I just can't find the right way to finish it.
There already is a CanClose method in the code base I use, which is empty by default. It's in the AppInit class where the MainWindow is opened. What I did in the constructor is this:
[ImportingConstructor]
public AppInit(MainWindow mainWindow, [ImportMany] IEnumerable<IClosingValidator> closingValidator)
{
this.mainWindow = mainWindow;
this.closingValidator = closingValidator;
}
That was the idea of my teacher. Now in the CanClose method I can iterate through these closing validations and return true or false, like so:
public Boolean CanClose()
{
foreach (var validation in this.closingValidator)
{
var result = validation.CanClose();
if (result == false)
{
return false;
}
}
return true;
}
The ClosingValidator currently looks like the following, which I think is wrong, but I need to build the dialog somewhere. The whole thing works, but the flag indicating whether the process in question is running is in the ViewModel of another project, meaning this confirmation dialog is always shown.
[Export(typeof(IClosingValidator))]
[PartCreationPolicy(CreationPolicy.NonShared)]
public class ClosingValidator : IClosingValidator
{
private readonly IMessageDialog messageDialog;
private readonly IOverlayEffect overlayEffect;
[ImportingConstructor]
public ClosingValidator(IMessageDialog messageDialog, IOverlayEffect overlayEffect)
{
this.messageDialog = messageDialog;
this.overlayEffect = overlayEffect;
}
public Boolean CanClose()
{
using (this.overlayEffect.Apply())
{
var result = this.messageDialog.ShowDialog(
new MessageDialogArgs(Resources.Resources.ConfirmClosingApplicationTitle,
Resources.Resources.ConfirmClosingApplicationMessage,
MessageBoxButton.YesNo,
MessageBoxImage.SystemQuestion));
if (result == MessageBoxResult.Yes)
{
return true;
}
}
return false;
}
I think my question comes down to this:
Where do I build my dialog and how do I use a boolean flag from the ViewModel to determine whether to show the dialog in the first place? I'm relatively new to MEF, so sorry anything's unclear.
Edit: I think the idea was that I can use that interface to implement further closing validations at some point in the future.
EDIT 3:
Simplified ViewModel implementation (The actual viewModel has too many parameters):
[Export]
public class TocViewModel
{
[ImportingConstructor]
public TocViewModel(MeasurementSequenceExecution measurementSequenceExecution)
{
this.measurementSequenceExecution = measurementSequenceExecution;
}
public Boolean CanApplicationClose
{
get { return !this.measurementSequenceExecution.IsMeasurementSequenceRunning; }
set
{
this.measurementSequenceExecution.IsMeasurementSequenceRunning = !value;
}
}
The IClosingValidator implementation:
[Export(typeof(IClosingValidator))]
[PartCreationPolicy(CreationPolicy.NonShared)]
public class ClosingValidator : IClosingValidator
{
[ImportingConstructor]
public ClosingValidator()
{
}
public Boolean CanApplicationClose { get; }
The IClosingValidator interface:
public interface IClosingValidator
{
Boolean CanApplicationClose { get; }
}
The class handling the closing:
[Export(typeof(IApp))]
public class AppInit : IApp
{
[ImportingConstructor]
public AppInit(MainWindow mainWindow,
[ImportMany(typeof(IClosingValidator))] IEnumerable<IClosingValidator> closingValidatorClients,
IOverlayEffect overlayEffect,
IMessageDialog messageDialog)
{
this.mainWindow = mainWindow;
this.closingValidatorClients = closingValidatorClients;
this.overlayEffect = overlayEffect;
this.messageDialog = messageDialog;
}
public Boolean CanClose()
{
if (this.closingValidatorClients != null)
{
foreach (var client in this.closingValidatorClients)
{
if (!client.CanApplicationClose)
{
using (this.overlayEffect.Apply())
{
var result = this.messageDialog.ShowDialog(
new MessageDialogArgs(Resources.Resources.ConfirmClosingApplicationTitle,
Resources.Resources.ConfirmClosingApplicationMessage,
MessageBoxButton.YesNo,
MessageBoxImage.SystemQuestion));
if (result == MessageBoxResult.Yes)
{
return true;
}
return false;
}
}
}
}
return true;
}
private readonly IEnumerable<IClosingValidator> closingValidatorClients;
private readonly MainWindow mainWindow;
private readonly IMessageDialog messageDialog;
private readonly IOverlayEffect overlayEffect;
UPDATE
I made it work, the suggestion to Export the ViewModel with typeof(IClosingValidator) was right, I just had to add a second Export, not replace the default one, didn't know you could have 2 of them. So now with 2 ExportAttributes it works!
I think your implementation of IClosingValidator is at the wrong place.
I have a similar project and what I do is the following:
I have a Interface like you IClosingValidator:
public interface IConfirmShellClosing
{
/// <summary>
/// Gets a value that indicates whether the shell window can be closed.
/// </summary>
bool CanShellClose { get; }
}
This interface is implemented by all ViewModels which should be asked, if the shell can be closed. In your case all ViewModels where the process can be running should implement this interface. So each ViewModel for itself will implement the CanShellClose Property and decide if the process is running in this context. Only if all ViewModels return true for this, the Window can be closed.
Then, in your instance of the window, you can subscribe to the WindowClosing Event and ask all registered ViewModels, if the Window can be closed. This implementation goes to your ViewModel of the Window (or the code behind file):
[ImportMany(typeof(Lazy<IConfirmShellClosing>))]
private IEnumerable<Lazy<IConfirmShellClosing>> _confirmShellClosingClients;
private void ExecuteWindowClosing(CancelEventArgs args)
{
if (_confirmShellClosingClients != null)
{
foreach (var client in _confirmShellClosingClients)
{
if (!client.Value.CanShellClose)
{
// Show your Dialog here and handle the answer
}
}
}
}
I hope this will help.
EDIT:
Okay, you still have a few mistakes in the implementation of your ViewModel and the Validator.
First of all, the Class ClosingValidator is not needed anymore. You want to give the responsibility to the ViewModels, and not to a central validator class.
After that, we need to change the ViewModel like this:
[Export]
public class TocViewModel : IClosingValidator
{
[ImportingConstructor]
public TocViewModel(MeasurementSequenceExecution measurementSequenceExecution)
{
this.measurementSequenceExecution = measurementSequenceExecution;
}
public Boolean CanApplicationClose
{
get { return !this.measurementSequenceExecution.IsMeasurementSequenceRunning; }
set
{
this.measurementSequenceExecution.IsMeasurementSequenceRunning = !value;
}
}
What is happening now? The ViewModel implements the IClosingValidator Interface, so it has to implement the CanShellClose Property. In this property, you can define the logic, in which this ViewModel can decide if the Shell can be closed or not. If you ever add an other ViewModel, it can implement the interface as well and has a different logic for the closing.
In the Importing in the Application itself, all classes which are implementing the IClosingValidator interface are imported and then asked, if the porperty is true or false.
EDIT 2:
I have 3 .dll (HelpingProject, InterfaceProject and ViewModelProject) All 3 should be in the directory where the compositionContainer is searching. In my case, I built the container like this:
var catalog = new AggregateCatalog();
catalog.Catalogs.Add(new DirectoryCatalog(#"C:\Projects\HelpingSolution\HelpingWpfProject\bin\Debug"));
var container = new CompositionContainer(catalog);
container.ComposeParts(this);
So the Debug folder will be scanned to find matching exports. I would recommend you search for the this code in your codebase and have a look at where your container is looking for the exports. This does not have to be only one folder, but can also be a plugin folder or different locations. You can find a pretty good introduction here.
Related
Say I have a class that receives data over a TCP stream, parses it and changes it's properties accordingly.
public static class SomeClass
{
static bool myBool;
static string myMessage;
public static void ToggleBool()
{
myBool = !myBool;
// Do some other stuff here
}
public static UpdateMessage(string message)
{
System.Diagnostics.Debug.WriteLine(message);
ProcessMessage(message);
myMessage = message;
}
}
Now what I want to do is have a WPF "Debugging Window" that will visually display the settings. I want to basically run a loop that updates parts of the window accordingly.
Something like:
public partial class LogWindow : Window
{
public MainWindow()
{
InitializeComponent();
}
public Async Task UpdateUI()
{
while(checkForUpdates)
{
myCheckbox.IsChecked = await SomeClass.UpdatedBoolValue();
string newMessage = await SomeClass.NewMessageRCVD();
txtBox.Append(newMessage);
}
}
}
But that has 2 obvious issues. One, I have no idea how I would make a function that doesn't burn CPU by constantly checking with a while loop. I imagine I could use a getter/setter approach though. Two, I have to update both in order for that loop to run again.
What's the best approach to this? How do update just the parts of the UI that need to be updated?
EDIT: Similar question: Write an Async method that will await a bool
Depends on how complex a implementation/your needs are.
From your example if you made SomeClass implement INotifyPropertyChanged you could easily attach a WPF window to it, and through binding the window would update automatically without any form of a loop.
If your talking about multiple classes and you want to have them all display the property information in the same window, your best bet would probably be to create a queue. In each property you wish to keep track of have the setter write to the queue. (global or singleton) Then you can easily front that information in a window, or multiple via an Observer pattern. Can also set it up to it never writes to the queue in production, or with conditional compile statements production wouldn't even have the code if that is your desire.
The best way to do this is with data binding.
So we need to first define where our data is coming from. This is called the Context. This is going to come from a ViewModel which is an MVVM term. If you aren't aware of MVVM, don't worry, this can just come from any class you have. In the backend .xaml.cs code we need to add the class to our windows's DataContext. Here's what that looks like:
public partial class DebugView : Window
{
public DebugView()
{
InitializeComponent();
DataContext = new DebugViewModel();
}
}
And in our WPF's XAML file for the window we will have a label and textbox that is defined as such:
<Label Content="{Binding ClientCount, FallbackValue='Clients: 00'}" ... />
<TextBox Text="{Binding Port, UpdateSourceTrigger=PropertyChanged}" ... />
The text of a label is it's "content" while the text of a textbox is just "text." We add the binding keyword in there and now the text for each will be linked to the variables ClientCount and Port, repstively. So our DebugViewModel class will look like this at first:
private string _ClientCount;
public string ClientCount
{
get { return _ClientCount; }
set { _ClientCount= value; RaisePropertyChanged("ClientCount"); }
}
private string _Port;
public string Port
{
get { return _Port; }
set { _Port= value; RaisePropertyChanged("Port"); }
}
Now you don't have a Function called RaisePropertyChanged() so what I did (and I think is common practice) was I made a base class that implements the INotifyPropertyChanged and handles all the work there.
So our base class, called BaseViewModel will inherit from the INotifyPropertyChanged class, and setup everything for us. That just looks like this (feel free to just copy paste and use as is):
using System.ComponentModel;
public class BaseViewModel : INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged;
internal void RaisePropertyChanged(string prop)
{
PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(prop));
}
// Other functions we want all ViewModels to have
}
and so then our DebugViewModel class will look like such:
public class ServerViewModel : BaseViewModel
{
private string _ClientCount;
public string ClientCount
{
get { return _ClientCount; }
set { _ClientCount= value; RaisePropertyChanged("ClientCount"); }
}
private string _Port;
public string Port
{
get { return _Port; }
set { _Port= value; RaisePropertyChanged("Port"); }
}
public DebugViewModel()
{
// Initialize to default values
ClientCount = $"Clients {server.clientCount}";
Port = $"{server.port}";
}
// Rest of code
}
And then when you start your program it will autopopulate the fields and you when you change the data in the textbox, the string will change, and vice versa. The UpdateSourceTrigger=PropertyChanged part of our XAML declaration makes it so that the variable is updated as soon as the data in the textbox is changed (default behavior is when the textbox loses focus. e.g. you tab to the next textbox or you click away).
This is pretty cool because you can validate input dynamically as it's typed, as well as not having to worry about switching to the UI thread to update the UI, and IMO makes the code look simpler just by having it bound like this.
This is my first MVVM app, and I am wondering how to switch to another view after the user is done with the OpenFileDialog.
The changing view technique currently using is borrowed from here.
In other word, how to call :
private void ExecuteGridViewCommand()
{
CurrentViewModel = MainViewModel._gridViewModel;
}
The problem rises since I couldn't track when the user clicks the Open button of the Dialog since the Dialog is not a XAML control.
private static ViewModelBase _currentViewModel;
public ViewModelBase CurrentViewModel
{
get { return _currentViewModel; }
set
{
if (_currentViewModel != value)
{
_currentViewModel = value;
OnPropertyChanged();
}
}
}
Somebody earlier sent an answer (deleted) that was inspiring (thanks) even though it didn't work out of the box, maybe due to instantiating a new instance of ViewModelLocator().
It was something like this:
private readonly MainViewModel _mainViewModel = (new ViewModelLocator().Main);
_mainViewModel.ExcuteGridView();
After tweaking, now I have this, and it works:
ViewModelLocator.Main.ExcuteGridView();
In order for this to work though, I had to declare the Main as static inside the ViewModelLocator:
public static MainViewModel Main
{
get
{
return _main;
}
}
I have a big problem with MVVM design. I am trying to catch every PropertyChanged of my inner nested objects, including futhermore propertchanged of their nested objects, inside my ViewModel but I dont know how to do it.
Here is my structure:
class MyVM
{
public MyVM()
{
this.SomeData = new SomeData();
this.SomeData.NestedObj = new MyNestedDat();
this.SomeData.Str = "This tiggers propertychanged inside MyDat class";
// this triggers propertychanged event inside MyNestedDat class
this.SomeData.NestedObj.Num = 123;
}
// and here should be a method where i catch all possibe propertychanges from my nested objets and their nested objets, how do i do that?
public MyDat SomeData
{
get;
set;
}
}
class MyDat : INotifyPropertyChanged
{
private string str;
public string Str;
{
get { return this.str;}
set
{
this.str = value;
this.PropertyChanged(this, "Str");
}
}
publicMyNestedDat NestedObj
{
get;
set;
}
}
class MyNestedDat : INotifyPropertyChanged
{
private int num;
public int Num
{
get{ return this.num;}
set
{
this.num = value;
this.PropertyChanged(this, "Num");
}
}
}
How do i get this to work? I am really clueless where to start.
MyNestedDat class throws PropertyChanged, MyDat class throws propertychanged and i want to catch them all inside my viewmodel. How can i do that?
In my opinion there are a few conceptual things wrong with what you are asking. Just imagine you get a solution that works for your scenario (that you are happy with) and consider the following:
What happens if another layer is added? do you still expect it to work the same?
Should property changes be propagated (viewModel1.propA notifies viewModel2.PropA)?
Should property changes be transformed (viewModel1.SomeProp notifies ViewModel2.AnotherProp)?
Is performance a concern? how will this perform if you need to propagate the property changed events through many levels?
This should be raising alarm bells that the current approach is not the right path to tread.
What you need is a way to provide communication between your viewModels in a loosely coupled way so that you viewModels do not even need to know about each others existence. The beauty of this is that this will also work in other situations not just for property changes.
For your case of property changed events, one viewModel wants to know when something happens (it could be something other than a property changed event, remember). This means the other viewModel needs some way of saying "Hey, a property has changed" (or "My state has changed", "That database call has finished" etc).
Now in C# you can provide events which provide this feature....except, now your objects know about each other which leaves you with the same problem you had before.
To overcome this problem you need another object, a mediator (lets call it Messenger in this example), whose sole purpose is to handle the message passing between the objects so that they can live in ignorance of each other.
The general idea is this. In the viewModel that provides notifications you might do something like this:
public string MyProp
{
get { return _myProp; }
set
{
_mProp = value;
OnPropertyChanged("MyProp");
Messenger.PostMessage(new VMChangedMessage { ViewModel = this, PropertyName = "MyProp" });
}
}
And in the viewModel that is interested in the event you might do something like this:
public class ViewModel2
{
public ViewModel2()
{
Messenger.Subscribe<VMChangedMessage>(handleMessage);
}
private void handleMessage(VMChangedMessage msg)
{
// Do something with the information here...
}
}
Notice that the two viewModels never reference each other. They are now loosely-coupled.
There are a number of pre-existing implementations already available and it isn't difficult to create your own (the messenger basically keeps a list of objects that are interested in a certain message and iterates the list when it needs to notify the interested parties). There are a few things that can be implemented differently (some implementations just pass string messages around rather than encapsulating the information in objects, and some handle the clean-up of observers automatically).
I would recommend using Josh Smiths (excellent) MVVM Foundation which includes a messenger class. It's also open source so you can see how it works.
There is no clear constraint about what PropertyName should contains in PropertyChangedEventArgs.
See Subscribe to INotifyPropertyChanged for nested (child) objects.
Here is an example :
class A : BaseObjectImplementingINotifyPropertyChanged {
private string m_name;
public string Name {
get { return m_name; }
set {
if(m_name != value) {
m_name = value;
RaisePropertyChanged("Name");
}
}
}
}
class B : BaseObjectImplementingINotifyPropertyChanged {
private A m_a;
public A A {
get { return m_a; }
set {
if(m_a != value) {
if(m_a != null) m_a.PropertyChanged -= OnAPropertyChanged;
m_a = value;
if(m_a != null) m_a.PropertyChanged += OnAPropertyChanged;
RaisePropertyChanged("A");
}
}
}
private void OnAPropertyChanged(object sender, PropertyChangedEventArgs e) {
RaisePropertyChanged("A." + e.PropertyName);
}
}
B b = new B();
b.PropertyChanged += (s, e) => { Console.WriteLine(e.PropertyName); };
b.A.Name = "Blah"; // Will print "A.Name"
The best thing to do here is to separate the idea of a Model and a ViewModel.
By having a ViewModel object that is flatter than the Model you can avoid this scenario. Using an automatic mapping tool like Automapper then allows you to map the Model to the ViewModel and vice versa.
https://github.com/AutoMapper/AutoMapper/wiki/Flattening
class MyDatViewModel : INotifyPropertyChanged
{
public string Str
{
// ... Get Set
}
public int NestedObjNum
{
// ... Get set
}
}
// Configure AutoMapper
Mapper.CreateMap<MyDat, MyDatViewModel>();
// Perform mapping
MyDatViewModel viewModel = Mapper.Map<MyDat, MyDatViewModel>(someData);
I've started a project usinjg MS Unity as my IOC container and have two questions regarding overriding parameters.
public interface ITab
{
bool AllowVisible {get;set;}
}
class Tab : ITab
{
IViewModel vm;
public Tab(IViewModel vm)
{
this.vm = vm;
}
public bool allowVisible = false;
public bool AllowVisible
{
get{ return allowVisible};
set{ allowVisible = vlaue};
}
}
public interface IViewModule
{
string Name;
}
public class ViewModel
{
public string Name;
}
1) How do i set up the Tab type in unity so that i can pass in true or false to the AllowVisible property as a paramater? I dont want to have to add the
additional line of tab.AllowVisible = true; as in the case below
void Main()
{
ITab tab = unityContainer.RegisterType<ITab, Tab>();
tab.AllowVisible = true;
}
2) If i already have an instance of the ViewModel, such as vm in the case below, how do i make the container resolve the Tab object while passing in the vm object into its constructor? Currently when i resolve for the tab object, the container creates another instance of the ViewModel. I want the vm instance to get used as the tab objects viewmodel?
void Main()
{
unityContainer.RegisterType<IViewModel, ViewModel>();
unityContainer.RegisterType<ITab, Tab>();
ViewModel vm = unityContainer.Resolve<IViewModel>();
ITab tab = unityContainer.RegisterType<ITab, Tab>();
}
If you automatically want to assign a value to the AllowVisible property of your ITab implementation then you can use the InjectionProperty type provided by Unity.
You can do this in a fluent way, for example:
IUnityContainer myContainer = new UnityContainer();
myContainer.Configure<InjectedMembers>()
.ConfigureInjectionFor<MyObject>(
new InjectionProperty("MyProperty"),
new InjectionProperty("MyStringProperty", "SomeText"))
);
A bit more concrete:
container.RegisterType<ITab, Tab>();
container.RegisterType<ITab, Tab>(
new InjectionProperty("AllowVisible", true)
);
For more information on how to inject constructor parameters, property values...etc, check out:
http://msdn.microsoft.com/en-us/library/ff650036.aspx
As for the second part of you question, you must pass constructor parameters (IViewModel) to Unity's Resolve(...) method when you resolve an implementation for an ITab.
This question has been asked before on SO, check out:
Can I pass constructor parameters to Unity's Resolve() method?
For completeness' sake:
var viewModel = container.Resolve<IViewModel>();
container.Resolve<ITab>(new ParameterOverrides<Tab> { { "vm", viewModel} });"
I'm working on building up an MVP application (C# Winforms). My initial version is at Critique my simple MVP Winforms app ... Now I'm increasing the complexity. I've broken out the code to handle two separate text fields into two view/presenter pairs. It's a trivial example, but it's to work out the details of multiple presenters sharing the same model.
My questions are about the model:
I am basically using a property changed event raised by the model for notifying views that something has changed. Is that a good approach? What if it gets to the point where I have 100 or 1000 properties? Is it still practical at that point?
Is instantiating the model in each presenter with NoteModel _model = NoteModel.Instance the correct approach? Note that I do want to make sure all of the presenters are sharing the same data.
If there is a better approach, I'm open to suggestions ....
My code looks like this:
NoteModel.cs
public class NoteModel : INotifyPropertyChanged
{
private static NoteModel _instance = null;
public static NoteModel Instance
{
get { return _instance; }
}
static NoteModel()
{
_instance = new NoteModel();
}
private NoteModel()
{
Initialize();
}
public string Filename { get; set; }
public bool IsDirty { get; set; }
public readonly string DefaultName = "Untitled.txt";
string _sText;
public string TheText
{
get { return _sText; }
set
{
_sText = value;
PropertyHasChanged("TheText");
}
}
string _sMoreText;
public string MoreText
{
get { return _sMoreText; }
set
{
_sMoreText = value;
PropertyHasChanged("MoreText");
}
}
public void Initialize()
{
Filename = DefaultName;
TheText = String.Empty;
MoreText = String.Empty;
IsDirty = false;
}
private void PropertyHasChanged(string sPropName)
{
IsDirty = true;
if (PropertyChanged != null)
{
PropertyChanged(this, new PropertyChangedEventArgs(sPropName));
}
}
public event PropertyChangedEventHandler PropertyChanged;
}
TextEditorPresenter.cs
public class TextEditorPresenter
{
ITextEditorView _view;
NoteModel _model = NoteModel.Instance;
public TextEditorPresenter(ITextEditorView view)//, NoteModel model)
{
//_model = model;
_view = view;
_model.PropertyChanged += new PropertyChangedEventHandler(model_PropertyChanged);
}
void model_PropertyChanged(object sender, PropertyChangedEventArgs e)
{
if (e.PropertyName == "TheText")
_view.TheText = _model.TheText;
}
public void TextModified()
{
_model.TheText = _view.TheText;
}
public void ClearView()
{
_view.TheText = String.Empty;
}
}
TextEditor2Presenter.cs is essentially the same except it operates on _model.MoreText instead of _model.TheText.
ITextEditorView.cs
public interface ITextEditorView
{
string TheText { get; set; }
}
ITextEditor2View.cs
public interface ITextEditor2View
{
string MoreText { get; set; }
}
This approach is good. However, if you are looking at having hundred (thousands even!) of Properties then I think you might have a God class (anti-pattern). There aren't many good classes with 100 properties. Instead consider breaking up your model into smaller classes. Furthermore, you don't need to have a separate event for each property. If the model is changed at all you can fire a single event (which might include information describing the change) and the views can handle it from there.
I would avoid using the Singleton pattern unless you actually are sure you want it to apply. Instead, change the constructor for all your views to take in an instance of the model.
Remember, in any layered application, it's normal for the domain model to transcend all layers.
Thus, I would have your presenter pass your Note instance to the view (which no doubt is a Control of some sort), and then let databinding through a BindingSource take over. Once you're using databinding, then the controls will automatically listen to the PropertyChanged event and update accordingly without the need for extra code on your part. Event-based notification is the appropriate use here no matter how many properties are being monitored as only the objects that care about the change will take action (vs. having many objects taking action unnecessarily).
Typically, you get your entity instances from a lower layer. For example, you could implement a service that returns your Note instances. Anytime you ask that service for Note #3, it returns the same instance of Note that it created from persisted data. You could further more add another item to your business layer to supplement your presenters - it could be call a WorkItem or a Controller. All of your presenters could consult their WorkItem instance to get the current instance of Note upon which the user will be working.
I would consider looking into examples of how the Composite Application Block (or CAB) uses these patterns to create smart client applications. It's all design patterns and OO principles, the implementation of which is well worth the effort.
To Question 1: Implementing INotifyPropertyChanged seems to be a good idea to me. Probably you would however split the many properties into some classes.
To Question 2: I am currently using a Singleton pattern for sharing my MVP Model with multiple presenters. I am happy so far, as this guarantees, that there is really ever only one instance of my model.