I'm currently trying to create an application with Prism and I have some problems with communication between modules.
I have a StatusModule which basically shows Statusmessages, but can also show the user that some work is in progress (indeterminate), show different icons, show / hide the control and so on.
For that normally i'd use a status object that has all these properties and use it as a parameter, but because in prism strong coupling is advised I don't know how I should do it.
Creating 4-5 Events for every property is probably bad practice, .. i also thought of creating an interface in my "Interaction" Module where the event's and resources are.
What would you guys recommend?
Many events for status might indeed not be the best solution; however if there's one or two that are used a lot (like showing a status message in a statusbar), I would expose them as events anyway for convenience.
For the rest, you can expose the StatusModule, or rather an interface IStatusModule that is implemented by StatusModule, via MEF or Unity depending on what you use. This way any component that wants to show status imports the IStatusModule and uses it.
Related
I am currently developing a Microsoft Word Add-In that communicates with a backend via webservices. The dialogs in this Add-In are created with WPF and I make use of the MVVM pattern. The viewmodels communicate with the repository over services. In order to decouple viewmodel and services I use the DI-container framework Unity.
There is some kind of state (I call it "Context", similar to the http-context) that depends on the active document at the time a window/viewModel was created. This context contains stuff like the active user.
Since a picture is worth more than a thousand words, I prepared a diagram to illustrate the design.
Now my problem is, that when a service method is called, the service needs to know what the active context is in order to process the request.
At the moment I am avoiding this problem by having one service for each document. But since this cuts across the statelessness of services, I don't consider it as a durable solution.
I also considered passing the context to the viewModel, so that I can pass it back to the service when calling a method there. But I see three problems here:
Technical Problems:
Each time I want to resolve a Window with Unity I would have to pass a ParameterOverride-object with the context - what creates dependencies to the concrete viewModel implementation.
=> Or is there a better way to achieve this with unity?
Cosmetical Problems:
I would have to pass the Context as object since the class for it is part of the startup-project and the ViewModels are not. When I now want to obtain data from the context, I'd have to cast it.
Consider a windowViewModel that contains data for a TreeView with hundreds of TreeViewItems. I would have to pass the Context to each of these "TreeItemViewModels" if I'd want to call a service-method in one of these.
So I'm wondering if there is a way of automatically "injecting" (maybe reflection?) the context into the viewModel at runtime without the viewModel knowing anything about it. This is probably impossible to achieve with Unity, but I'm always open to being convinced.
On the other side, when a method on a service is called, the injected context is automatically extracted (maybe by some kind of layer in front the actual service) and saved into some globally accessible property.
I hope that some of you can help me. I appreciate any kind of idea.
I’ve an Interface with many textEdit fields. But any Fields have dependencies to others.
For example:
When textfield_1 is filled, textvield_3 and 4 disabled. But my Layout is Dynamic and I don’t want to Code this dependencies Hard.
Does anyone have an Idea or Solution to Save or hold this dependencies in my Application? And how can I check it.
If I understood your intent correctly I would say the basics would come from ViewModel (as in MVVM design pattern). You could go with the simple INotifyPropertyChanged route or something more "reactive" like RxUI: http://www.reactiveui.net/
All changes happen in the ViewModel (so you can also share it across platforms) and the UI just reacts to changes in the ViewModel data.
I have some GUI controls in WinForms application. For example i have log control which logs each progress application makes so i can debug quickly, currently all "databinding" is on MainForm. I can create separate control but still it is coupled too much with application logic.
I've got advice to use partial MVC pattern in which I will update some object which saves log items and log control will get to this object and load the data to control.
I don't know how to implement it, besides creating a Class which will hold the data I need to load.
I have problems with Threads as many processes in the application run in different Threads.
Do you know any example of this done in C#?
I read the thread Mr Moose links to, but what finally got me going was this: http://www.c-sharpcorner.com/UploadFile/rmcochran/implementing-the-passive-view-a-derivative-of-the%C2%A0model-view-control/ is part of a series the guy wrote on this exact issue. I am currently using this scheme and am quite happy with it.
I added a ObservableDictionary to some of my Model classes. Key based lookup is nice for a lot of cases.
He has a whole series of articles with different implementations that may be more suitable for you.
I've read MEF documentation on Codeplex and I'm trying to figure out how to accomplish my task:
I would like to build an application framework that has standard components that can be used to do some common work (like displaying a list of records from a database). Plugins should be reused many times with different configuration each time. (eg. I have 5 windows in an application where I display record lists, each with different type of entity, different columns, each one should have it's own extension points like for displaying record details that should be satisfied with a different copy of another common plugin).
Is MEF suitable for such a scenario? How should I define contracts? Should I use metadata? Can I define relationships using configuration files?
Yes, you can use MEF. MEF supports NonShared instantiation of objects using the PartCreationPolicy attribute:
[PartCreationPolicy(CreationPolicy.NonShared)]
More information on this here.
Personally I'd do the wiring and configuration after the importing of the component on the target. However I am not sure how generic you want your application to be, if you are making a 'framework' to do certain solutions in I can imagine you want the configuration to be separate. You can go all-over-board and make an ISuperDuperGridConfiguration and import these on the constructor [ImportingConstructor] of your grid plugin. From within your target (where the grids get imported) set the location of the grid to the grid plugin (like main grid, side grid) and use the data stored in ISuperDuperGridConfiguration to further config the grid plugin itself.
However, you can easily go 'too far' with MEF, depending on your goals. We have a completely MEF componentized UI for an application with customized needs for every single customer. Sometimes I have the urge to put single buttons from the ribbon in a MEF extension.
As you can see, depending on your needs, you can and sometimes will go too far.
I don't think you'd need metadata especially in your case, but maybe someone else can share a different opinion on this ;-).
I hope this answers your question, if not please comment so I can highlight more aspects. All in all using MEF has been very positive for us, and we are using it far beyond a 'hello world' so to say. So at least you have that!
I've been looking in to the Composite Application Library, and it's great, but I'm having trouble deciding when to use the EventAggregator... or rather - when NOT to use it.
Looking at the StockTraderRI example, I'm even more confused. They are using the EventAggregator in some cases, and "classic" events in other cases (in for example the IAccountPositionService interface).
I've already decided to use it for communication with a heavy work task, that should run on a background thread. In this case the EventAggregator offers marshalling of threads behind the scenes, so I don't have to worry much about that. Besides that I like the decoupling this approach offers.
So my question is: When I've started using the EventAggregator in my application, why not use it for all custom events?
This is a good question. In Composite WPF (Prism) there are 3 possible ways to communicate between parts of your app. One way is to use Commanding, which is used only to pass UI-triggered actions down the road to the actual code implementing that action. Another way is to use Shared Services, where multiple parts hold a reference to the same Service (Singleton) and they handle various events on that service in the classical way. For disconnected and asynchronous communication, as you already stated, the best way is to use the Event Aggregator (which follows closely Martin Fowler's pattern).
Now, when to and not to use it:
Use it when you need to communicate between modules. (for example, a Task module needs to be notified when a Task is created by any other module).
Use it when you have multiple possible receivers or sources of the same event. For example, you have a list of objects and you want to refresh it whenever an object of that type is saved or created. Instead of holding references to all open edit/create screens, you just subscribe to this specific event.
Don't use it when you only have to subscribe to normal events in the Model View Presenter area. For example, if your presenter listens to changes in the Model (for example the Model implements INotifyPropertyChanged) and your Presenter needs to react on such changes, it's better that your Presenter handles directly the PropertyChanged event of the Model instead of diverting such events through the Event Aggregator. So, if both the sender and receiver are in the same unit, there's no need to "broadcast" such events to the whole application.
I hope this answers your question.