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.
Related
Right now I am coding an application and am thinking that there has to be a better solution to what I am doing right now.
I have a main window which shall handle the settings of the program. Then I have further classes and windows. For example a language handler class and a form that is handling the user input needed for the "main function".
However, until now I always have to pass my main window to each of this classes, because the language handler shall be able to change the main window's strings. And the other form should also be able to pass data to the main Window.
If we imagine there will be much more classes and every class needs a copy of the main window this would consume a lot of resources depending on the main window's "size".
So, is there a better/more efficient way to communicate between these classes.
Common way to do that is to use observer pattern, which in .NET is events system. Simply said, your classes subscribe to each other's events and perform action when event is raised. As noted in comment, passing references is not memory heavy, but it results in tight coupling between different pieces of your code - observer pattern addresses that problem.
Another option is to consider you classes as services. Code them to an interface and then use dependency injection (aka Inversion of Control) to build up the object graph (You tell the IoC container you want a frmSomething and it will determine what services/classes it needs and instantiate them as appropriate).
This means that:
you only ever have to code against an interface not an implementation
your code is loosely coupled (You can swap an OldTranslator for a NewTranslator and as long as they both comply to the same interface, nothing has to be changed except the configuration of the container)
you can develop high-level features which rely on services that haven't been written yet and your code will compile
You can very easily change how your app works, at run-time if needs be, by changing what classes/services are registered in your container.
Have a look at Unity for the MS-Supported DI container. Castle Windsor is a popular alternative but there are many more
It's worth noting that passing a "Copy" of the main window around as you've said is not a bad thing - You're actrually only passing a reference (effectively a pointer) to the main window (since anything more complex than the real primitives are reference types). This means that there's very little overhead whatsoever
I would suggest you to use Galasoft or Prism MVVM implementations. There you can use their messaging service which is quite easy to use. The class that needs info just sends a message to the subscriber and they in turn can send all data needed. I think that this is the easiest way to handle communication.
in addition to the ans given by IVAN.. if we look at a higher level view without all those terminologies then you should probably create a static class which would server as InMemoryStorage and defines fields on it to save information
this what you will have complete control over what is being shared and multiple components can change it
moreover you can defined getters and setters and raise an event whenever the property is changed so that different forms or windows (views) can subscribe to the change and take action accordingly
I have a Metro app consisting of several pages, all deriving from LayoutAwarePage. I've implemented navigation to and back from them. This works like a charm. What I want to do now is to share common data between these views like for example:
access to a model, let's Name it MyModel
an instance of a controller, let's name it MyController
common business logic, let's name it MyLogic
In the past I was used to "inject" those dependencies via constructor. This is now not possible anymore (right?). How can I do this otherwise keeping in mind that I want to avoid:
singletons (because of testing)
public static properties (which is similar to singletons)
Is it ok to pass kind of a context object to the Frame.Navigate() method? Does anybody have a good advice?
P.S. I want to avoid using Frameworks like MVVM light or Cocoon.
Cheerio!
It sounds like you are looking for something very simple. If that is the case, I would just add a property to App.xaml.cs.
You set/get that property from anywhere in your application with something like (App.Current as App).MyProperty. Very brute force but it works.
I have also seen the same approach but with a master container assigned to App.xaml.cs property, then an extension method with a getContainer() method - just to reduce the number of times you have to write (App.Current as App).
Ok, I guess I found a good solution for me [1]. It's still not exactly what I was looking for, because it's using the MVVM light toolkit and its Messenger concept - but it's clean.
[1] http://forums.silverlight.net/p/200771/468507.aspx
The dependency property framework is a general UI Framework that can be needed outside WPF. So is there a way to use it for Winforms or ASP.NET UI for example ?
Update: I mean can I declare a few namespaces and use dependency property framework in winforms and asp.net ?
I vaguely remember trying to use Routed Events in my own non-WPF code, and it turned out to be a nightmare. Both Routed Events and Dependency Objects need to be owned by DependencyObjects, which in turn inherit from System.Windows.Threading.DispatcherObject. At the very least, it would be horribly ugly -- if not impossible.
I would suggest using INotifyPropertyChanged and INotifyCollectionChanged etc. instead if you can. It's a little more code per property since you need a backing field and to call the NotifyChanged event, but it's much more straightforward.
Most .NET IoC containers and dependency injection frameworks work within the confines of the framework.
This means they can work with ASP.NET and Winforms.
If this is not what you are asking, can you please clarify your question? It is not entirely clear what you are asking.
In regards to dependency properties (now that I understand exactly what you are talking about):
You can use them in winforms and webforms, since these are also written in .NET. As you posted in your comment, yes, simply importing several namespaces should be enough.
What features of the dependency property sub-system after you after? If you're specifically after binding support, you could something like Truss as a general binding manager.
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.
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