When looking through the main app bootstrapper, the InjectionProxy is used to register instances and interfaces. I noticed that interfaces can be registered as InstanceType.SingleInstance (done for the database in the Tesla app) or InstanceType.EachResolve. Further delving of the InjectionProxy code shows that instances are always SingleInstance.
What is the difference between SingleInstance and EachResolve, why would I choose my interfaces to be one or the other, and why are instances always set to be SingleIstance?
SingleInstance means that it will only ever create one copy of the class, for use in anything that requests it.
EachResolve, means that each class that has this interface injected into it, will get a new instance of the interface.
It depends on what you want for your app. In most cases, SingleInstance is what you want, but EachResolve is there incase your situation requires a new instance, instead of the same one used throughout your app.
Related
I need to listen for changes in the Qt3D scene tree (node added, removed, property changed, etc...).
I found class QSceneChange but documentation is missing and I can't find a usage example.
How to use this class to watch for node create/destroy events?
I know this question is a bit old (and maybe you have already found an answer) but I'll try to shed some light on this issue:
You can listen for changes on the nodes you created. I.e. when you add a QNode you can connect its signals to your implemented slots. The following signals are available:
Node removed: nodeDestroyed()
Parent changed (i.e. the node was set to a different parent): parentChanged()
These two signals are emitted by QNode, and thus, all the inheriting classes. There is no Node added signal because you know when you created nodes and add them to the framegraph. All framegraph classes inherit from QNode so they emit those signals (QEntity, QAttribute, ...).
All other signals depend on the respective inheriting class and are thus emitted by them.
For example, if you want to listen to changes in the properties of a QAttribute you have to connect slots to the signals of that class. You can see such a list here.
Some more explanation:
The QSceneChange is not meant for you but for the back-end. Qt3D uses a front-end - back-end scheme where you use front-end nodes like QEntity or QAttribute or whatever - i.e. all classes inheriting QNode are front-end nodes (see the "Inherited By:" section in the link).
When you visit their GitHub repo and look for example at the render folder, you see that there's a backend and a frontend folder.
The frontend folder holds all the Q-classes, like QEntity and so on. The backend folder holds the corresponding back-end nodes, Entity in this case. I'm not sure why they didn't separate everything properly but if you check out the framegraph folder you'll see the same pattern again - some classes starting with a Q and the corresponding classes without the Q.
Now, the front-end notifies the back-end about changes in its nodes using QSceneChange so that the back-end can act accordingly. The creators of Qt3D probably thought it not necessary to have a signal that notifies you about all changes. most of the time you would want to subscribe to one specific property changed event, like byteStrideChanged() in QAttribute (Why would you want to react to each and every change?).
I assume you could somehow intercept those QSceneChange events (new implementation of QNode or something like that) but they are not meant for you.
I am learning pureMVC and trying to implement the framework into one of my application. I have follwing case:
My main application has Canvas which is used to add different kind of custom components. One of the custom component is a "Search Component" (multiple instances are created on page). My search component has a textfiled and a search button and initiate search in following steps:
1-Clicking search button dispatches a custom event, that custom event keeps reference of search component as a property.
2-My AppMediator listens the custom event and get the reference of current search component along with search text.
3-Mediator send a notification (sentNotification(AppConstants.SEARCH_CLICKED, component)).
4-I have registered a command with SEARCH_CLICKED notification.
5-Command retrieve a WebserviceProxy and invokes its Search(text) method.
6-WebserviceProxy talks to remote webservice and uses asyncToken to get results.
My Questions is:
My Command has the reference to the custom search component when it start search but search webservice takes some time and get the result. How can i handle the results back to custom search component that initiated the search. Since i have multiple instances of search component. What is the best place to keep the reference of that component, should i add a variables in WebserviceProxy to keep that reference and hand the results over to it, or i have to create a Global Proxy to keep references of such components?
Thanks
I have been using PureMVC for some years and I like it!
I think you have not yet understood roles and collaboration of main components.
You should not have any dependencies between Commands and UI-elements. Your Mediator has to get the concrete value from your UI-component and send it through the Notification. In this case the Command and the Proxy will get only a text value and it is no matter, what is the source of it! Suppose you will change your UI after some time and you will have another components on the user side to determine the search value. In your case you would have to change the Proxy and the Command. It would be bad.
Proxy may not have any information about Commands and Mediators. It can only offer its functions to let another components interact with it AND it sends Notifications with new information after getting it without knowing who is interesting in it.
Read the description of the framework once more and write your questions.
I had some problems with understanding the stuff too, I see your problem.
Based on Anton's answer, i re-think and tried to separate dependencis. As a result, i tried to mediate each instance of Search Widget with "SearchMediator" separately by providing different ID to the constructor of Mediator. Now, when search widget intiates a new search, it's mediator invokes the Command, Command invokes a method of Proxy to do actual search and fetch results from DB and sends a Notification. SearchMediator takes care about that notification and hands over the results to appropriate UI.
I have two unrelated databases and I need to pass data back and forth between them. Right now I have created two separate entity models - one for each database - but this is causing issues in my code b/c I have to do a Using nameofcontext / End Using and when I try to then use some of the results from the first section of the code in a second Using nameofcontext / End Using it doesn't like it - b/c I've closed the connection to the first database!
Since this is a website, you could create one instance of each context in Global.asax's BeginRequest event, and dispose of that instance in EndRequest. Doing that means during the rest of the event lifecycle, you have contexts that will remain open and can do what you need, but you still know they're being properly disposed.
That's how I've gotten around issues like this.
Note: Don't store the context in a global shared variable because that will share it between multiple requests and havok will ensure. HttpContext.Current.Items lets you store something that is easy to retrieve in your code but is specific to the current request, so that's a safe place to store them.
If you have a lot of small classes (that are often created and destroyed), and they all depend on the settings, how would you do that?
It would be nice not to have to connect each one to some kind of "settings changed" signal, and even if I did, all the settings will be updated, even those objects whose settings didn't change.
When faced with that myself, I've found it's better to control the save/load settings from a central place. Do you really need to save/load the settings on a regular basis or can you have a master object (likely with a list of the sub-objects) control when savings actually need to be done? Or, worst case, as the objects are created and destroyed have them update an in-memory setting map in the parent collection and save when it thinks it should be saved, rather than child object destruction.
One way of implementing it is given below.
If you wish, the central location for the settings can be a singleton derived from QAbstractItemModel, and you can easily connect the dataChanged(...) signal to various objects as necessary, to receive notifications about changed settings. Those objects can decide whether an applicable setting was changed. By judicious use of helper and shim classes, you can make it very easy to connect your "small classes" with notifications. This would address two issues inherent in the model driven approach to settings.
The possibly large number of subscribers, all receiving notifications about the settings they usually don't care about (the filtering issue).
The extra code needed to connect the subscriber with the item model, and the duplication of information as to what indices of the model are relevant (the selection issue).
Both filtering and selection can be dealt with by a shim class that receives all of the dataChanged notifications, and for each useful index maintains a list of subscribers. Only the slots of the "interested" objects would then be invoked. This class would maintain the list of subscriber-slot pairs on its own, without offering any signals for others to connect to. It'd use invokeMethod or a similar mechanism to invoke the slots.
The selection issue can be dealt with by observing that the subscriber classes will, upon initialization, query the model for initial values of all of the settings that affect their operation - that they are "interested" in. All you need is a temporary proxy model that you create for the duration of the initialization of the subscriber. The proxy model takes the QObject* instance of the caller, and records all of the model indices that were queried (passing them onto the singleton settings model). When the proxy model is finally destroyed at the return from the initialization of the subscriber class, it feeds the information about the model indices for this QObject to the singleton. A single additional call is needed to let the singleton know about the slot to call, but that's just like calling connect().
What I typically do is to create a class handling all my settings, with one instance per thread. To make it quicker to write this class, I implemented a couple of macros that let me define it like this:
L_DECLARE_SETTINGS(LSettingsTest, new QSettings("settings.ini", QSettings::IniFormat))
L_DEFINE_VALUE(QString, string1, QString("string1"))
L_DEFINE_VALUE(QSize, size, QSize(100, 100))
L_DEFINE_VALUE(double, temperature, -1)
L_DEFINE_VALUE(QByteArray, image, QByteArray())
L_END_CLASS
This class can be instantiated once per thread and then used without writing anything to the file. A particular instance of this class, returned from LSettingsTest::notifier(), emits signals when each property changes. If exposed to QML, each property work as regular Qt property and can be assigned, read and used in bindings.
I wrote more info here. This is the GitHub repo where I placed the macros.
suppose I have a domain classes:
public class Country
{
string name;
IList<Region> regions;
}
public class Region
{
string name;
IList<City> cities;
}
etc.
And I want to model this in a GUI in form of a tree.
public class Node<T>
{
T domainObject;
ObservableCollection<Node<T>> childNodes;
}
public class CountryNode : Node<Country>
{}
etc.
How can I automatically retrieve Region list changes for Country, City list changes for Region etc.?
One solution is to implement INotifyPropertyChanged on domain classes and change IList<> to ObservableCollection<>, but that feels kinda wrong because why should my domain model have resposibility to notify changes?
Another solution is to have that responsibility put upon the GUI/presentation layer, if some action led to adding a Region to a Country the presentation layer should add the new country to both the CountryNode.ChildNodes and the domain Country.Regions.
Any thoughts about this?
Rolling INotifyPropertyChanged into a solution is part of implementing eventing into your model. By nature, eventing itself is not out of line with the DDD mantra. In fact, it is one of the things that Evans has implied that has been missing from his earlier material. I don't remember exactly where, but he does mention it in this video; What I've learned about DDD since the book
In and of itself, impelemnting an eventing model is actually legitimate in the domain, because of the fact it introduces a decoupling between the domain and the other code in your system. All you are doing is saying that your domain has the capability of notifying interested parties in the fact that something has changed. It is the responsibility of the subscriber, then, to act upon it. I think that where the confusion lies is that you are only using an INotifyPropertyChanged implementation to relay back to an event sink. That event sink will then notify any subscribers, via a registered callback, that "something" has happened.
However, with that being said, your situation is one of the "fringe" scenarios that eventing does not apply all that well to. You are looking to see if you need to repopulate a UI when the list itself changes. At work, the current solution that we have uses an ObservableCollection. While it does work, I am not a fan of it. On the flip side, publishing a fact that one or more items in the list have changed is also problematic. For example, how would you determine the entropy of the list to best determine that it has changed?
Because of this, I would actually consider this to not be a concern of the domain. I do not think that what you are describing would be a requirement of the domain owner(s), but rather an artifact of the application architecture. If you were to query the services in the domain after the point that the change is made, they would return correctly and the application would still be what is out of step. There is nothing actually wrong inside the world of the domain at this momeent in time.
So, there are a few ways that I could see this being done. The most inefficient way would be to continually poll for changes directly against the model. You could also consider having some sort of marker that indicates that the list is dirty, although not using the domain model to do so. Once again, not that clean of a solution. You can apply those principles outside of the domain, however, to come up with a working solution.
If you have some sort of a shared caching mechanism, i.e. a distributed cache, you could implement a JIT-caching/eviction approach where inserts and updates would invalidate the cache (i.e. evict the cached items) and a subsequent request would load them back in. Then, you could actually put a marker into the cache itself that would indicate something identifiable as to when that item(s) was/were rebuilt. For example, if you have a cache item that contains a list of IDs for region, you could store the DateTime that it was JIT-ed along with it. The application could then keep track of what JIT-ed version it has, and only reload when it sees that the version has changed. You still have to poll, but it eliminates putting that responsibility into the domain itself, and if you are just polling for a smaller bit of data, it is better than rebuilding the entire thing every time.
Also, before overarchitecting a full-blown solution. Address the concern with the domain owner. It may be perfectly acceptable to him/her/them that you simply have a "Refresh" button or menu item somewhere. It is about compromise, as well, and I am fairly sure that most domain owners would have a preference of core functionality over certain types of issues.
About eventing - most valuable material I've seen comes from Udi Dahan and Greg Young.
One nice implementation of eventing which I'm eager to try out can be found here.
But start with understanding if that's really necessary as Joseph suggests.