First of i am not a UI developer and this is probably a very simple problem.
What i have is a external service that I subscribe to an event, when ever that event fires a service picks this up, manipulates the data in some way then gives the UI the data to display
What i am unsure of is how to archetect this and keep the dependancy between the service which will tell the UI to update and the UI as loose as possible.
Can anyone suggest a stratagy for this or post me some links on examples or an open source project to actually look at some working code.
I am using c# and ether wpf or winforms for this.
Cheers
Colin G
How simple is this application?
The simplest solution is to have the data access/manipulation in one object, and have the UI passed as an interface into that object. With the UI interface methods, you can give data to the UI but let the UI handle displaying the data in a GUI thread-safe manner.
If it's a more complex application, I'd say it would make more sense to look into something like MVC or MVP. Or MVVM for WPF, maybe look at Bea Costa's blog for databinding examples.
My solution to this problem is to create a timer in your ui, and have your ui subscribe to the 'onTick' method. Then, at every timer tick, have the UI look at the service and figure out what data to display.
There's a lot of ways to skin this cat, but without knowing a little more about your requirements and your existing infrastructure, let me suggest you use an EventBroker / Mediator for this. This is an easy way to implement a kind of Publisher / Subscriber type of relationship without worrying about too much of the plumbing.
If you are using Prism, I'd suggest using the EventAggregator.
If not, you might consider using the "Messenger" implementation of an EventBroker available with the MVVMFoundation stuff that John Smith wrote. It's not really dependent on you using MVVM or WPF and does what you are looking for:
http://mvvmfoundation.codeplex.com/
Hope this helps.
then gives the UI the data to display...
I would suggest you to have a service agent layer which will raise an event and pass a DTO. This event should be subscribed by the layer which contains objects bound to the UI. Once this layer receives the DTO, update the UI.
Related
I have been trying to use this version of an EventAggregator here
I have been using it in a Blazor Server app which is a rewrite of an Old Silverlight app which used an EventAggregator. However, I have had many issues with it. The latest of which it doesn't fire the events when it should (have no idea why it is not working correctly).
In any case, I am looking for an alternative pattern.
What I am looking for is a way to tell multiple components that the "CurrentCustomer" has changed, so that the components can update themselves.
Is there a recommended pattern or way to do this?
So far, the best thing I have found is the StateContainer as described: here It's just a simple class that holds state, and you can subscribe to it's events.
This is the only EventAggregator for Blazor that I have found: https://mikaelkoskinen.net/post/blazor-eventaggregator-2-0-0-auto-refresh
The only thing worthy of note is that the current default is the following:
builder.Services.AddScoped<EventAggregator.Blazor.IEventAggregator, EventAggregator.Blazor.EventAggregator>();//Use this.
//builder.Services.AddEventAggregator(); Not this. It adds it as a singleton which is NOT what we want. Change requested of author. The Events will be propagated to every user everywhere, instead of just the current user.
So I've just started developing C# WinForm applications and each project I've been working on seems to be larger and requires more user functionality. If I add all of the functionality to one form, obviously it can get out of control very quickly. My last project I would divide up the functionality into individual Forms, and whenever someone say wanted to perform "Feature1" I would instantiate Feature1 Form and show it as a dialog with the main Form as it's owner (so they couldn't click off it).
I'm just curious of what other methods are out there for keeping code organized within Forms. If you are forced to have tons of features/functionality on a single form is there a good way to keep items organized? I simply hate having a code file with hundreds/thousands of lines long.
The answer may simply be in the design, try to design the UI up front so you can utilize multiple forms?
Another example I faced. I created a Tab Control and had about 5 tabs. Those 5 tabs had tons of features and were all stored in the same CS file. What other options did I have? Create a new custom TabControl class with my specific functionality for that tab in it?
I don't mind reading, so if there are decent articles out there feel free to link them!
The go-to method is a Controller/Presenter. The idea is that the window should only be responsible for actually handling the UI events of its controls, and it should do so by calling methods on a Controller which do the real work for the window. The window can either have the handlers necessary or it may link the UI events directly to Controller methods; the former is usually the easier method, but it can be tempting to sneak in a line of code here or there that really should be in the Controller method. By doing this, you sever the layout and presentation logic in the Form class with the business logic in the Controller.
Mark Hall's suggestion of User Controls is also a good one. By creating UserControl classes for tabs or for common UI control combinations, you sever the logic responsible for laying out that part of the UI from the main form's code, and the control then just "drops in" and the window works with it in a much simpler way. This is a must for implementing custom but reusable controls; the fundamental tenet of DRY is that if you have two lines of code in two different places doing the same job to two different but interchangeable things, those lines of code should be merged into one place.
I have used UserControls in my projects to group functionality into separate objects that can then be added to your Form.
I tend to split my logic code from the UI as recommended. If you do this, you need to be somewhat cautious with how calls are made across the application to avoid Cross Thread Exceptions. I was taught to create delegates and events to update the UI from the logic class, but MSDN of course also has a lot of information on making thread safe calls.
I know this is a late answer, but if anyone still reads this question, another way to reduce the number of lines of code in your form is to use Data Bindings. If you are using properties, Data Bindings make it so that you don't have to constantly write handlers just to do something like PropertyName = textBox.Text;. Data Bindings work with both datasets and objects.
I'm using PRISM and MVVM in my modular Silverlight application. I'm still trying to figure out PROPER way to do interactions in MVVM fashion and 2 methods that PRISM and samples offer is not something I like for different reasons.
Method 1(PRISM): To use different region adapter. Basically, it involves attached properties on container and injecting view into region. This works almost 100% but negative of this method is that there is no good way to communicate results back. I can use EventAggregator but something doesn't feel right to raise event with data when interaction completed.
Method 2(PRISM): To use InteractionRequest. That involves trigger action and some big boilerplate XAML that I have to repeat on each view.
I'm thinking on creating something on my own which would require creating my own control which will have to be added to each view but with very little XAML and some kind of IPopupService that I can bind this control to. I can pass all needed data via PopupService but in order to actually make action of POPUP happen - I need to call method on this control and that falls apart in MVVM
I wonder how to call method on control in MVVM where view shouldn't be aware of VM ?
View has no option but be aware of VM, since it binds to it.
You could define some kind of a service indeed with a run-time implementation that would interact with the UI and design/test/debug implementation that does something else. You might also publish some events in your VM layer that the View layer would decide how to interpret.
First off, I don't think MVVM is a good choice if you are developing a UserControl that will be consumed by others. A lookless control is what you really should be developing. Jeremiah Morrill has a blog post about this subject.
With that said, you can set the datacontext with XAML if you have a default public constructor.
Inside ControlView.xaml put:
<UserControl.DataContext>
<local:ControlViewModel />
</UserControl.DataContext>
In C#:
I have a data class that is shared amongst several gui classes. I would like all of the gui classes that use it to be notified when some of the properties change, so they can keep the GUI up to date.
In a couple of the properties I have added delegates that the GUI classes can listen to for updates. This seems to work ok.
The problem I have is that more and more of the properties will require GUI notification. When that happens I will have to add more delegates. It also seems that this is adding an extra responsibility to the data class that it has to manage.
Is there some common pattern that I can use to monitor this class to extract this notification responsibility from the data class?
The common way of doing this is for the data class to implement INotifyPropertyChanged.
EDIT: If you have a lot of properties, this can lead to very repetitive code in the data class, and if you are binding to a UI, it might be best to use an AOP approach and intercept calls to the properties that you want to notify on. Most IoC containers have support for this sort of thing.
The pattern is called Observer. In .Net, events are one implementation of that pattern.
For the specific case of observing individual properties, the INotifyPropertyChanged interface should be used (as #Lee describes).
You don't say what GUI framework (WinForms, WPF) you are using, but there is the INotifyPropertyChanged interface. There is an How to guide on MSDN too.
You can just use the built-in System.EventHandler. That is a pretty standard pattern. You still need to define an event for each property that you want to monitor, but you don't need a separate delegate.
In Windows Forms there are several ways to notify GUI when some properties are chaged using Data Binding.
There are several types of Data binding in Windows Forms.
For simple data binding (data source with one object boud to one control) you can use INotifyPropertyChanged, or you can add events in this format: PropertyNameChanged for every property that you want update in GUI. And you should set Binding.ControlUpdateMode property to OnPropertyChanged.
For complex data binding (data source with many objects bound to control that can display many objects) you should use all from (1) and you should use BindingSource or BindingList or manually implement IBindingList;
For more information you should see this great books:
Windows Forms 2.0 Programming by Chris Sells
Data Binding with Windows Forms 2.0: Programming Smart Client Data Applications with .NET by Brian Noyes
Please excuse my ignorance, I only started coding in Silverlight recently.
I tried implementing the command pattern in Silverlight and hit a wall.
They say commands are great, because you can write them into xaml, so you can keep your code-behind clean, also you have loose coupling between your view and your viewmodel because there is no direct reference to the viewmodel in the view.
You can not keep your code-behind clean, because you can bind only one command to a control, and you have to decide which event will fire your command when you bind it. If a control has 30 events, you have to choose one for commanding. The other 29 will execute the other commands from event handlers from the code behind.
Loose coupling can be achieved more simply by dependency injection, commands add a useless layer of indirection that gives nothing extra, they only make it a bit harder to maintain your code. It is easier to maintain your code, when you are programming against an interface and see exactly what method gets called, then when you have to keep jumping between your command definitions and your viewmodel.
Did I miss anything, or commands are really not meant to be used for view and viewmodel interaction?
Please see the following question. This is why I don't get all the hype with commands:
How should I handle multiple events per control w/command pattern using MVVM in Silverlight?
Take a look at Prism (http://prism.codeplex.com) and their DelegateCommand<> infrastructure. Its a good solution for Silverlight and WPF to create commands in the ViewModel (or Presenter) and bind directly to it. Also in Silverlight 3, Behaviors can give you some of this same XAML-based syntax.
SL 2.0 is not so powerful as WPF, you will have to write some code behind :-(.
Not sure if you have read this article about MVVM and SL, talks about commands limitations on SL:
http://msdn.microsoft.com/en-us/magazine/dd458800.aspx
I believe that you could trick your event handlers with attached behavior pattern.
Please see following url for more information:
http://www.codeproject.com/KB/WPF/AttachedBehaviors.aspx