The composition root is the single place in your application where the composition of the object graphs for your application take place, using the dependency injection container (although how this is done is irrelevant, it could be using a container or could be done manually using pure DI). There should only be one place where … Read more
Yes, always! So this way even if your minifer converts $scope to variable a and $http to variable b, their identity is still preserved in the strings. See this page of AngularJS docs, scroll down to A Note on Minification. UPDATE Alternatively, you can use ng-annotate npm package in your build process to avoid this … Read more
Wow, can’t believe that Joel would favor this: var svc = new ShippingService(new ProductLocator(), new PricingService(), new InventoryService(), new TrackingRepository(new ConfigProvider()), new Logger(new EmailLogger(new ConfigProvider()))); over this: var svc = IoC.Resolve<IShippingService>(); Many folks don’t realize that your dependencies chain can become nested, and it quickly becomes unwieldy to wire them up manually. Even with factories, … Read more
The first question is the most difficult to answer. Is it bad practice to have Entities depend on outside classes? It’s certainly not the most common thing to do. If, for example, you inject a Repository into your Entities you effectively have an implementation of the Active Record pattern. Some people like this pattern for … Read more
You are right that if you use the container as a Service Locator, it’s more or less a glorified static factory. For lots of reasons I consider this an anti-pattern (also see this excerpt from my book). One of the wonderful benefits of Constructor Injection is that it makes violations of the Single Responsibility Principle … Read more
You need to define an AbstractBinder and register it in your JAX-RS application. The binder specifies how the dependency injection should create your classes. public class MyApplicationBinder extends AbstractBinder { @Override protected void configure() { bind(MyService.class).to(MyService.class); } } When @Inject is detected on a parameter or field of type MyService.class it is instantiated using the … Read more
This is actually simple to do once you understand that DI is about patterns and principles, not technology. To design the API in a DI Container-agnostic way, follow these general principles: Program to an interface, not an implementation This principle is actually a quote (from memory though) from Design Patterns, but it should always be … Read more
Any place where you need a run-time value to construct a particular dependency, Abstract Factory is the solution. Having Initialize methods on the interfaces smells of a Leaky Abstraction. In your case I would say that you should model the IMyIntf interface on how you need to use it – not how you intent to … Read more
NOTE: This answer talks about the Entity Framework’s DbContext, but it is applicable to any sort of Unit of Work implementation, such as LINQ to SQL’s DataContext, and NHibernate’s ISession. Let start by echoing Ian: Having a single DbContext for the whole application is a Bad Idea. The only situation where this makes sense is … Read more
@ManagedBean vs @Controller First of all, you should choose one framework to manage your beans. You should choose either JSF or Spring (or CDI) to manage your beans. Whilst the following works, it is fundamentally wrong: @ManagedBean // JSF-managed. @Controller // Spring-managed. public class BadBean {} You end up with two completely separate instances of … Read more