If I have a data/web service that multiple view models need access to what is the preferred "MVVM way"?
Do I have a global static service or do I pass in an instance of my service to all my view models? I personally can't see an advantage of one approach over the other.
Passing in an interfaced version of your service allows your class to be easily unit tested. With global static state, this is not as clean or as easy.
Making the class take an interface also defines the contract for your class. You're essentially saying, "ClassA requires IServiceA and IServiceB to function correctly". With global static state, there is no such contract.
In addition to using Dependency Injection also consider a ServiceLocater approach, where each ViewModel would, if not passed an instance of a service, would call to the ServiceLocator to obtain an instance of the registered service at run time.
Fowler on DI and ServiceLocator
MSDN on ServiceLocator
Related
Is there a way to make EasyMock's #TestSubject annottation to work when the test subject object is enhanced with CGLIB?
Scenario: the #TestSubject object is a Spring bean which was enhanced with CGLIB in order to apply some aspect (assuming that for some reason Spring couldn't use JDK-based proxy). In this case, simply using #TestSubject and EasyMockSupport.injectMocks(this) does not really work. EasyMock injects the mock, however during execution the mock is not actually used due to how the internals of a CGLIB enhanced class work. In the end it is used the original reference the object had, not the mock.
The only approach I know is to create a setter in the test subject, and to inject the mock manually calling the setter. However sometimes I do not have access/permission/time to change the subject code to include the setter.
cglib classes are always final what prevents the creation of another proxy. This is therefore not possible to do. Rather, you would need to discover that a class is a cglib proxy already and rather enhance its base class.
For a project I need to have a unique ID generator. So I thought about a Singleton with synchronized methods.
Since a Singleton following the traditional Singleton pattern (private static instance) is shared accross Sessions, I'm wondering if the #Singleton Annotation is working the same way?
The documentation says: Identifies a type that the injector only instantiates once.
Does it mean, that a #Singleton will be independent per User Session (which is bad for an id-generator)? Should I prefer an old school Singleton with Class.getInstance() over an Injection of an #Singleton-Bean?
Or should I use neither nor and provide the Service within an #ApplicationScoped bean?
it musst be guaranteed that only ONE thread, independent of the user session can access the method to generate the next id. (It's not solvable with auto-increment database ids)
Edit: JSF 2.2, CDI and javax.inject.* i'm talking about :)
All those kinds of singletons (static, #javax.inject.Singleton, #javax.ejb.Singleton and #javax.enterprise.context.ApplicationScoped) are created once per JVM.
An object that is created once per user session must be annotated with #javax.enterprise.context.SessionScoped so no, singletons will not be instantiated per user session.
Notice that there are two #Singleton annotations, one in javax.inject and the other in the javax.ejb package. I'm referring to them by their fully-qualified names to avoid confusion.
The differences between all those singletons are subtle and I'm not sure I know all the implications, but a few come to mind:
#javax.ejb.Singleton is managed by the EJB container and so it can handle transactions (#javax.ejb.TransactionAttribute), read/write locking and time-outs (#javax.ejb.Lock, #javax.ejb.AccessTimeout), application startup (#javax.ejb.Startup, #javax.ejb.DependsOn) and so on.
#javax.enterprise.context.ApplicationScoped is managed by the CDI container, so you won't have the transaction and locking features that EJB has (unless you use a post-1.0 CDI that has added transactions), but you still have lots of nice things such as #javax.enterprise.inject.Produces, #javax.annotation.PostConstruct, #javax.inject.Named, #javax.enterprise.inject.Disposes (but many of these features are available to EJBs too).
#javax.inject.Singleton is similar to #ApplicationScoped, except that there is no proxy object (clients will have a reference to the object directly). There will be less indirection to reach the real object, but this might cause some issues related to serialization (see this: http://docs.jboss.org/weld/reference/latest-2.2/en-US/html_single/#_the_singleton_pseudo_scope)
A plain static field is simple and just works, but it's controlled by the class loader so in order to understand how/when they are instantiated and garbage collected (if ever), you will need to understand how class loaders work and how your application server manages its class loaders (when restarting, redeploying, etc.). See this question for more details.
javax.inject.Singleton - When used on your bean, you have to implement writeResolve() and readReplace to avoid any serialization issues. Use it judiciously based on what your bean actually has in it.
javax.enterprise.context.ApplicationScoped - Allows the container to proxy the bean and take care of serialization process automatically. This is recommended to avoid unprecedented issues.
For More information refer this page number 45.
I have a class running in a winforms app which uses EF Code First. The DbContext is created via DI through the class constructor. All works well.
The problem is the data being referenced is also being modified via a web site, using the same DI pattern with EF Code First, and the data changes are not being reflected in the context instance in the winforms app.
I can solve this by recreating the DbContext object in winforms every time I access it, but seems to be more of a service location pattern to me?
Is there a true DI technique to achieve this?
Or should I remove the context from the DI and use service location?
Were you not happy with the answer to your other question (http://stackoverflow.com/questions/7657643/how-to-force-ef-code-first-to-query-the-database) which suggested using Detach, AsNoTracking or Overwrite Changes?
1) Maybe you could pass an interface that has the ability to create a DbContext, instead of the context itself.
using(var context = _contextFactory.Create()) {
var entity = from table in context.Blah...;
}
The Create method could either create the concrete class itself (defeating the DI pattern a bit), or use service location to have one created for it. Not that nice, but it's better than embedding service location calls everywhere and still means you're controlling the lifecycle yourself.
2) Change the WinForm to read from a webservice run by the website, effectively similar to disabling caching.
3) Deep in the heart of MVC (well not really that deep) it is referencing the DI container directly and using it as a service locator to pass as arguments for newly created objects. Technically you could do something similar in WinForms, but it would need you to split your application up into little chunks (controllers) that don't have a very long lifetime. Maybe it's worth looking at some MVC/MVP frameworks for WinForms, although I found myself cringing at most I saw after a quick google.
The problem is the data being referenced is also being modified via a web site, using the same DI pattern with EF Code First, and the data changes are not being reflected in the context instance in the winforms app.
This is a problem with your expectations.
If your web service and window forms app are in separate processes, they won't share in-memory data.
If you want to sync their in-memory data, simply re-query in one context after committing to the database in the other. This is the same as trying to share data between different SQL connections.
I can solve this by recreating the DbContext object in winforms every time I access it, but seems to be more of a service location pattern to me?
If you want to recreate the DbContext repeatedly, you could use an abstract factory to allow manual re-creation of the object, yet allow you to inject the specific implementation into the factory.
This is not (necessarily) the Service Locator pattern, and you would have to ensure that you manually dispose your DbContext instances. I'd give you some example code, but different DI containers have totally different ways of accomplishing a factory pattern.
Or you could simply make sure that you commit your data on the web service side, and re-query the data on the WinForms app side.
I need to generate service proxies for multiple WCF services within the same namespace, which is not possible when using the Add Service Reference function of Visual Studio.
How can I do this in an automated way? I've considered using SLsvcUtil, but that would require that I make sure that I have my WCF services accessible, and, assuming I'm using the ASP.NET Development Server, I'd need to manually check the URL.
Ideally, I'd have some way of specifying an assembly, a service type, the configuration (web|app.config) and a target namespace, and then my code would be generated. Any Ideas?
Edit
To clarify, I'm trying to solve the same problem that is outlined in this connect issue:
http://connect.microsoft.com/VisualStudio/feedback/details/426791/adding-multiple-service-references-from-same-application-should-not-require-multiple-namespaces
I want a no-hassle, automated way to generate service proxies within a single namespace. It's unacceptable for me to have to specify a unique namespace for each service reference. Using SLsvcUtil is an option, but it requires that I have my service up-and-running so it can read the metadata - which is a problem because I don't always have the latest version of the service running at any given point in time.
The "Add Service Reference" functionality in VS handles this well - it automatically hosts the service just long enough to grab the metadata, and then generates the service contract interfaces and proxies. Once again, it requires that each service be code-gen'd in its own, unique namespace, which I don't want.
All I need is a way to generate the service proxies with a single, shared namespace, without having to go through the hassle of manually hosting and firing up an instance of my services. Ideally, I'd just double click a script file.
What I normally do is to inform a composite namespace. When the "Add Service Reference" dialog pops up, I put in the namespace something like Services.ServiceA or Services.ServiceB. Then all service namespaces share the common root Services.*.
If I'm understanding the question correctly, you're concerned because the way Add Service Reference functions, the ServiceContract interfaces are not exactly the same as the ones you define in your source assembly.
The only real difference is that the ServiceContract interface that Add Service Reference generates for SL has asynchronous operations defined (since SL doesn't support synchronous WCF calls). The rest of it (the XXXClient : ClientBase class) can be completely bypassed if you just use the ChannelFactory<TServiceContractInterface> directly.
I personally ended up sharing the synchronous ServiceContract interface, but creating a service contract with asynchronous operations using a System.Reflection.Emit.TypeBuilder. Then using a custom ChannelFactory, I created a wrapper around the dynamically generated asynchronous ServiceContract interface.
I hope that helps.
I am working on a WPF application, using the MVVM Pattern.
Each ViewModel will need access to a security object, that essentially provides information about the rights the user has. Because this object only needs to be populated once at start up, and because populating it is (at least potentially) expensive, I want to keep it in state for the lifetime of the application.
I can make it a static variable in App, which would make it available to the whole application (at least that's my understanding). This would make my ViewModel implementations very difficult to test, since the App.SecurityObject call would be inline in each ViewModel. I would have to make sure App was available for each test and mock the App.SecurityObject call (I'm not even sure this would work, actually).
We are using StructureMap, so I could create a SecurityObjectProvider and configure a it with a Singleton lifecycle in the container, and simply make it part of every ViewModel constructor. The downside would be that (as I said) the provider would have to be part of every View Model constructor.
There are other, hacky workarounds I can think of, but they would involve creating methods (perhaps in the View Model base class) that would allow injecting the security object after instantiation for testing purpose only. I usually try to avoid this kind "for testing only" code.
It seems like this would be a common problem , but I can't find any SO questions that are completely on point.
Security concerns are often best adressed by Thread.CurrentPrincipal. If it's at all possible to fit your security concerns into that model (calling Principal.IsInRole and so on) that is by far the desirable solution.
It's pretty easy to unit test because you just need to set Thread.CurrentPrincipal before invoking the SUT and then make sure you revert it to its original value in the Fixture Teardown phase.
If Thread.CurrentPrincipal doesn't suit your need, I would suggest either an injected dependency or a Decorator that handles security. Security is often a Cross-Cutting Concern, so it is often preferable to handle it as declaratively as possible. In other words, if you can model it by Guards and Assertions, you don't need to actively call it, and you would be able to use a more AOP-like approach (such as a Decorator).
If that's not possible either, you can model it as an Ambient Context. This may look a bit like the Service Locator anti-pattern, but the difference is that it's strongly typed and has a Local Default that ensures that it never throws NullReferenceExceptions or their like because it protects its invariants.
The service locator pattern might help you out. You still implement the functionality as a service, but you have your VMs go through a static class to obtain the service, rather than have it injected:
var securityService = ServiceLocator.Resolve<ISecurityService>();
When running unit tests, you can configure your service locator to return mocks/stubs.
I think I would use some kind of Service Locator to get object. And in tests I would mock it out.