I need to know how to expose multiple interfaces in a same object path under a service using QDbus bindings in the dbus server. I use qdbusxml2cpp to generate the adaptor classes.
The structure below could make the question clear.
MyService (Service Name)
/org/demo (Object path)
org.demo.interface1 (Adaptor classA)
methodA
signalA
org.demo.interface2 (Adaptor classB)
methodB
signalB
Please help me by giving the example code if possible.
I just spent the last few hours fighting with this myself. Here it is how to do it:
class MyService : public QObject, public QDBusContext has private members `m_interface1' and 'm_interface2'
the interface1 and interface2 classes are derived from the QDBusAbstractAdaptor (derived) class
when instantiating interface1 and interface2 use as parent MyService pointer for them
register MyService pointer to D-Bus using QDBusConnection::registerObject("/", myService)
Related
currently I use $inject to inject components in my controller:
export class MyClass{
public static $inject = [
"$depedencyA",
"$depedencyB",
"$depedencyC"
];
constructor(
private $depedencyA: IDependencyA,
private $depedencyB: IDependencyB,
private $depedencyC: IDependencyC
)
{
}
}
This works fine when creating an instance of MyClass like let myClassInstance=new MyClass();
But what if I want to pass a depedency that cannot be directly injected by the class itself?
let myClassInstance=new MyClass(anotherDependency);
Well of course I have to extend MyClass to accept this parameter in the constructor
constructor(
private $depedencyA: IDependencyA,
private $depedencyB: IDependencyB,
private $depedencyC: IDependencyC,
private $anotherDependency: any
)
{
}
..but then the injection cannot work anymore because the parameters array does not match the actual constructur signature anymore.
How do I work around this?
This won't work: let myClassInstance=new MyClass(); because you're not letting angular wire up the dependencies for you. You're now responsible for providing all of the dependencies for this class which you haven't in your example.
If you're newing these objects up yourself, then nothing changes when you add another dependency - you will have to provide this manually as well.
You can't really do partial injection with angularjs' DI. You will need to either new that object up yourself and provide all the dependencies, or you will have to register the new dependency as a service of some kind.
I'm currently making an application with WPF and MVVM Light toolkit.
I have this view model :
public class MainViewModel : ViewModelBase
{
// Instance of service which is used for sending email.
private IEmailService _emailService;
// Get/set instance of service which is used for sending email.
public IEmailService EmailService
{
get
{
return _emailService;
}
set
{
Set("EmailService", ref _emailService, value);
}
}
public MainViewModel()
{
_emailService = new ServiceLocator.Current.GetInstance<IEmailService>();
}
}
Email service is a service which handles sending/processing emails. When user interacts with an element on the screen, email service is called (this has been registered in ServiceLocator)
I wonder if my implement is correct with MVVM design pattern or not. And are there any better ways to inject service into view model (the current approach takes a lot of time declaring initializing property)
I wonder if my implement is correct with MVVM design pattern or not.
Dependency injection has nothing to do with the MVVM pattern really. MVVM is about separation of concern between user interface controls and their logic. Dependency injection enables you to inject a class with any objects it needs without the class having to create these objects itself.
And are there any better ways to inject service into view model (the current approach takes a lot of time declaring initializing property)
If it makes no sense for the view model class to exist without a reference to the service, you should use constructor dependency injection instead of injecting the dependency through a property. You can read more about this here:
Dependency injection through constructors or property setters?
Using your current implementation it is possible to use the view model class without the service:
MainViewModel vm = new MainViewModel();
vm.EmailService = null;
A better implementation would be something like this:
public class MainViewModel : ViewModelBase
{
// Instance of service which is used for sending email.
private readonly IEmailService _emailService;
public MainViewModel(IEmailService emailService = null)
{
_emailService = emailService ?? ServiceLocator.Current.GetInstance<IEmailService>();
if(_emailService is null)
throw new ArgumentNullException(nameof(emailService));
}
}
This makes sure that the view model class always has a valid reference to an IEmailService. It also makes it possible to inject it with any implementation of the IEmailService interface when you construct the object.
I am looking for a maven plugin that will auto generate EntityProxy interfaces from my domain classes.
The class could implement the various interfaces to be generated and then each field or accessor method could use an annotation.
public class MyDomainObject implements MyDOProxyFoo, MyDOProxyBar {
#ExposedBy({MyDOProxyFoo.class})
public String foo;
#ExposedBy({MyDOProxyBar.class})
public String bar;
#ExposedBy({MyDOProxyFoo.class,MyDOProxyBar.class})
public String foobar;
...
}
Then the getters/setters for the respective fields would be in the respective generated interfaces.
You could do something like a readonly attribute in the annotation to only expose a getter in the specified interfaces.
...
#ExposedBy({MyDOProxyBar.class}, readOnly = {MyDOProxyFoo.class})
public String bar;
...
I could run something like
mvn rfproxygen:generateproxies
and I would have all my proxy interfaces nicely created in the generated sources directory.
I guess the argument is deciding wether you should have service data binding logic in your domain model.
I don't know a maven plugin that is capable of generating proxies but there is an issue addressing this for GWTP. Maybe this will of interests for you if it's finished.
I've begun experimenting with dependency injection (in particular, MEF) for one of my projects, which has a number of different extensibility points. I'm starting to get a feel for what I can do with MEF, but I'd like to hear from others who have more experience with the technology. A few specific cases:
My main use case at the moment is exposing various singleton-like services that my extensions make use of. My Framework assembly exposes service interfaces and my Engine assembly contains concrete implementations. This works well, but I may not want to allow all of my extensions to have access to all of my services. Is there a good way within MEF to limit which particular imports I allow a newly instantiated extension to resolve?
This particular application has extension objects that I repeatedly instantiate. I can import multiple types of Controllers and Machines, which are instantiated in different combinations for a Project. I couldn't find a good way to do this with MEF, so I'm doing my own type discovery and instantiation. Is there a good way to do this within MEF or other DI frameworks?
I welcome input on any other things to watch out for or surprising capabilities you've discovered that have changed the way you architect.
Is there a good way within MEF to
limit which particular imports I allow
a newly instantiated extension to
resolve?
Load the extension code in a separate container, and make sure that the restricted parts are not available in that container. Let's simplify the situation to these classes to construct an example:
[Export]
public class MyExtension
{
[Import]
public PublicService Service { get; set; }
}
[Export]
public class PublicService
{
}
[Export]
public class InternalService
{
}
[Export]
public class Program
{
[Import]
public MyExtension Extension { get; set; }
[Import]
public PublicService Service1 { get; set; }
[Import]
public InternalService Service2 { get; set; }
}
The goal is to allow MyExtension to import PublicService, but not InternalService. Internal code like Program should be able to import anything. You can achieve that like this:
var publicCatalog = new TypeCatalog(typeof(PublicService), typeof(MyExtension));
var publicContainer = new CompositionContainer(publicCatalog);
var internalCatalog = new TypeCatalog(typeof(Program), typeof(InternalService));
var internalContainer =
new CompositionContainer(internalCatalog, publicContainer);
var program = internalContainer.GetExport<Program>();
This code will not throw a composition exception. If you now change the import on MyExtension to the forbidden InternalService, you will get a composition exception as desired.
A side effect of this set-up is that PublicService cannot import any private services either, just like MyExtension. This kind of makes sense, because otherwise nothing would stop PublicService from exposing a private service via a property.
I have used TypeCatalog for the example, but in practice you should probably use something like the FilteredCatalog sample.
This particular application has
extension objects that I repeatedly
instantiate. I can import multiple
types of Controllers and Machines,
which are instantiated in different
combinations for a Project. I couldn't
find a good way to do this with MEF,
so I'm doing my own type discovery and
instantiation. Is there a good way to
do this within MEF or other DI
frameworks?
You might just be after the PartCreationPolicy attribute, which controls whether a part is shared (as in, created only once per container) or instantiated multiple times for each import. You can also specify the RequiredCreationPolicy parameter in an import attribute.
If that doesn't solve your problem, take a look at the PartCreator sample in the MEF sources (though note that it will probably soon be renamed to ExportFactory, it already has been in the silverlight edition of MEF).
I've got a CustomersModule.cs with the following Initialize() method:
public void Initialize()
{
container.RegisterType<ICustomersRepository, CustomersRepository>(new ContainerControlledLifetimeManager());
CustomersPresenter customersPresenter = this.container.Resolve<CustomersPresenter>();
}
The class I resolve from the container looks like this:
class CustomersPresenter
{
private CustomersView view;
private ICustomersRepository customersRespository;
public CustomersPresenter(CustomersView view,
ICustomersRepository customersRepository,
TestWhatever testWhatever)
{
this.view = view;
this.customersRespository = customersRepository;
}
}
The TestWhatever class is just a dummy class I created:
public class TestWhatever
{
public string Title { get; set; }
public TestWhatever()
{
Title = "this is the title";
}
}
Yet the container happily resolves CustomersPresenter even though I never registered it, and also the container somehow finds TestWhatever, instantiates it, and injects it into CustomersPresenter.
I was quite surprised to realize this since I couldn't find anywhere in the Prism documentation which explicitly stated that the container was so automatic.
So this is great, but it what else is the container doing that I don't know about i.e. what else can it do that I don't know about? For example, can I inject classes from other modules and if the modules happen to be loaded the container will inject them, and if not, it will inject a null?
There is nothing magical going on. You are specifying concrete types, so naturally they are resolvable, because if we have the Type object, we can call a constructor on it.
class Fred { };
Fred f1 = new Fred();
Type t = typeof(Fred);
Fred f2 = (Fred)t.GetConstructor(Type.EmptyTypes).Invoke(null);
The last line above is effectively what happens, the type t having been found by using typeof on the type parameter you give to Resolve.
If the type cannot be constructed by new (because it's in some unknown separate codebase) then you wouldn't be able to give it as a type parameter to Resolve.
In the second case, it is constructor injection, but it's still a known concrete constructable type. Via reflection, the Unity framework can get an array of all the Types of the parameters to the constructor. The type TestWhatever is constructable, so there is no ambiguity or difficulty over what to construct.
As to your concern about separate modules (assemblies), if you move TestWhatever to another assembly, that will not change the lines of code you've written; it will just mean that you have to add a reference to the other assembly to get this one to build. And then TestWhatever is still an unambiguously refeferenced constructable type, so it can be constructed by Unity.
In other words, if you can refer to the type in code, you can get a Type object, and so at runtime it will be directly constructable.
Response to comment:
If you delete the class TestWhatever, you will get a compile-time error, because you refer to that type in your code. So it won't be possible to get a runtime by doing that.
The decoupling is still in effect in this arrangement, because you could register a specific instance of TestWhatever, so every call to Resolve<TestWhatever>() will get the same instance, rather than constructing a new one.
The reason this works is because Unity is designed for it. When you Resolve with a concrete type, Unity looks to see if it can resolve from the container. If it cannot, then it just goes and instantiates the type resolving it's dependencies. It's really quite simple.