I wanted to ask what operations should be pleaced in ConstructUsing and what in WhenStarted. In fact things which normally are placed in contructor like configuration read, initialization in case of service should be placed in WhenStarted IMO in order to refresh all things during service restart, so what is left for ConstructUsing? just newing up the class and that's all? But in that case why not newing up in WhenStarted as well?
Thanks in advance
ConstructUsing defines how to create your service, which can indeed just be a new(), or alternatively another way of obtaining the service:
For example, using IoC:
// Release in WhenStopped()
sc.ConstructUsing(() => container.Resolve<IMyService>());
Another option is to use an existing instance of the service:
sc.ConstructUsing(() => serviceInstance);
WhenStarted, on the other hand, defines what actions to take when the instance of the service starts, and so requires an instance to configure: you wouldn't be able to create the service here:
sc.WhenStarted(service => service.Start());
Related
I'm new to Magento 2. In Magento 1, as you know, we can call any method from other class(es) more easily, thanks to Mage::
In Magento 2, I notice every time I want to use a method(s) from other class(es), I have to inject the dependency(ies) first which can make the constructor looks very long with so many injections. I read we can use object manager but it's not preferable. Not sure why.
The most obvious advantage for me using dependencies instead of object manager, is that you can leverage it anywhere in your class. Using object manager you have to call the methods for each function individually. It may seem a more practical approach at first, but with more complex code your functions will bloat because you always have to refer to object manager instead of referring to the method directly via dependency. I'd rather have a "big block of construction" on top instead of all these object manager instances in my functions.
Also, it can be quite tricky to use object manager correctly. Maybe have a look at this:
https://magento.stackexchange.com/questions/117098/magento-2-to-use-or-not-to-use-the-objectmanager-directly
I couldn't find any reference with this functionality. Shall I just implement a helper method in the builder to read fields in StateTransition object and populate the chain configureTransition() call by myself??
Just to confirm not to reinvent the wheels.
UPDATE:
I'm trying to use StateMachineBuilder to configure with some pre-defined states and transitions in a properties file. In Builder, they use this chained call to generate configuration:
builder.configureTransitions().withExternal().source(s1)....
What I have in mind is, everything read from the file is stored in an object, the spring sm library has this StateTransition object. But as far as I know from the API, there is no way to use it directly to configure a state machine. Instead, I can read individual fields in the object and use the chained call above.
Thanks!
If you want to do it like that, what you mentioned is pretty much only option. Hopefully we get a real support for external state machine definition, i.e. tracked in https://github.com/spring-projects/spring-statemachine/issues/78.
i would like to ask a little question about task adaptor in q2.
i have a class that extends TaskAdaptor and an xml class with to instantiate it.
so my question is, how do i get the object instance created by the xml in java?
Thank you very much for any help provided.
You use the NameRegistrar to get a reference to your object, but please keep in mind that the TaskAdaptor was created in the early Q2 days in order to reuse Tasks created to run under QSP (QSP was the original version, Q2 stands for 'QSP version 2').
I don't think we have any of those old tasks in the jPOS system now, so I wonder why you need the TaskAdaptor; if you have Tasks of your own, it might be easier to upgrade them to full QBeans (just by extending QBeanSupport or implementing the simple QBean interface).
Please take a look at http://jpos.org/doc/proguide-draft.pdf, there's a chapter about writing your own jPOS Services (aka QBeans).
I'm new to MVC, EF and the like so I followed the MVC3 tutorial at http://www.asp.net/mvc and set up an application (not yet finished with everything though).
Here's the "architecture" of my application so far
GenericRepository
PropertyRepository inherits GenericRepository for "Property" Entity
HomeController which has the PropertyRepository as Member.
Example:
public class HomeController
{
private readonly PropertyRepository _propertyRepository
= new PropertyRepository(new ConfigurationDbContext());
}
Now let's consider the following:
I have a Method in my GenericRepository that takes quite some time, invoking 6 queries which need to be in one transaction in order to maintain integrity. My google results yeldet that SaveChanges() is considered as one transaction - so if I make multiple changes to my context and then call SaveChanges() I can be "sure" that these changes are "atomic" on the SQL Server. Right? Wrong?
Furthermore, there's is an action method that calls _propertyRepository.InvokeLongAndComplex() Method.
I just found out: MVC creates a new controller for each request. So I end up with multiple PropertyRepositories which mess up my Database Integrity. (I have to maintain a linked list of my properties in the database, and if a user moves a property it needs 6 steps to change the list accordingly but that way I avoid looping through all entities when having thousands...)
I thougth about making my GenericRepository and my PropertyRepository static, so every HomeController is using the same Repository and synchronize the InvokeLongAndComplex Method to make sure there's only one Thread making changes to the DB at a time.
I have the suspicion that this idea is not a good solution but I fail to find a suitable solution for this problem - some guys say that's okay to have static repositories (what happens with the context though?). Some other guys say use IOC/DI (?), which sounds like a lot of work to set up (not even sure if that solves my problem...) but it seems that I could "tell" the container to always "inject" the same context object, the same Repository and then it would be enough to synchronize the InvokeLongAndComplex() method to not let multiple threads mess up the integrity.
Why aren't data repositories static?
Answer 2:
2) You often want to have 1 repository instance per-request to make it easier to ensure that uncommited changes from one user don't mess things up for another user.
why have a repository instance per-request doesn't it mess up my linked list again?
Can anyone give me an advice or share a best practice which I can follow?
No! You must have a new context for each request so even if you make your repositories static you will have to pass current context instance to each its method instead of maintaining single context inside repository.
What you mean by integrity in the first place? Are you dealing with transactions, concurrency issues or referential constraints? Handling all of these issues is your responsibility. EF will provide some basic infrastructure for that but the final solution is still up to your implementation.
I would like to use ServiceTracker in order to consume the services published by our company.
Instead of creating new ServiceTracker for each service I want to consume I thought it would be better to create just one with a filter and then get the services from it:
Filter filter = ctx.createFilter("(" + Constants.OBJECTCLASS + "=com.mycomp*)");
tracker = new ServiceTracker(ctx, filter, null);
The problem with this approach is that I then need to iterate over the service references the tracker had found examine their objectClass property and see if I can assign it to the service object which is very cumbersome and error prone due to casting that is required.
Any other ideas how to cunsume multiple services using more elegant way?
I think it is the wrong question :-) From the question I infer that you have a method that takes a service from your company and you want that method called. That is, somewhere in your code you need to be informed about a specific type com.mycomp.X, that is, you're not interested in general services from your company, you have a clear type dependency. In your question you assume that they need to be dispatched centrally which is usually not robust, error prone, and a maintenance hotspot; every time you have a new company service you need to update the dispatch method.
A MUCH better solution seems to be to use Declarative services and use bndtools with annotations. In that model, each place where you need service:
#Component public class SomeMyCompComponent {
...
#Reference
void foo( com.mycomp.X x ) { ... }
...
}
In this model, you do not need to centrally maintain a dispatcher, any class can get the services it needs when they need it. This model also accurately handles multiple dependencies and lots more goodies.
Maybe I do not understand the problem correctly because I inferred the problem from the solution you required. However, I think you try to abuse the Service Tracker for a task it was not intended to do.
Unfortunately, DS is not build into the framework as we should have done :-(
You could subclass ServiceTracker and add methods to provide direct access to the service types in which you are interested. For example, you could store the services in a typesafe heterogeneous container [1]. Then you would be able to call method on your ServiceTracker subclass which take the type of the service you are interested in and they could be easily looked up in the typesafe heterogeneous container.
[1] Effective Java, 2nd Ed., Item 29.