So, I recognize StackOverflow is littered with this question, but frequently no one explains why they want to do this. I'm hoping that by doing so a better answer floats to the top.
This guy did something close to what I want: Resolving IEnumerable of generic interfaces from Autofac container But not quite.
I recognize IGenericInterface<ObjectA> is not equivalent to IGenericInterface<ObjectB>.
That being said, I'd love to inject every IService<T> into a single constructor so that I can build a lookup. Honestly, I'd like to build an implementation very similar to DbContext.Set<T>
A few key players in my problem.
public interface IService<TMessage> where TMessage: IContractDTO
{
IQueryable<TMessage> BuildProjection();
}
Currently I'm injecting these one at a time
public class SomeController : BaseODataController<SomeEntityDTO>
{
public SomeController(IControllerServiceContext context, IService<SomeEntityDTO> service)
: base(context, service)
{
}
//DO STUFF
}
IControllerServiceContext is a composite interface with DbContext, AppSettings, and a few other common goodies I want in every controller.
In most cases this is good enough. However occasionally in support of logic for EntityA, I might need to do a quick lookup on B. I'd rather use IService<SomeEntityB>'s implementation of BuildProjections() than building out a redundancy in Controller A. If I inject each one I have a few that would become an 8 or 9 param constructor this way, for example
SO I got to thinking what if I was able to add an IServiceLookup to IControllerServiceContext then I would have everything I needed.
I Started down this path:
public class ServiceLookup<TContract>: IServiceLookup where TContract: BaseClass, IContractDTO
{
public ServiceLookup(IEnumerable<IService<TContract>> services)
{
//Build _Services
}
private readonly IDictionary<Type, object> _services;
public IService<TMessage> Service<TMessage>() where TMessage : class, IContractDTO
{
return (IService<TMessage>)(GetService(typeof(TMessage)));
}
private object GetService(Type type)
{
_services.TryGetValue(type, out var service);
return service;
}
}
For obvious reasons this can't be done with the current constructor.
But is there a way to get the dictionary that I do want, either by IIndex or an IEnumerable that I can build that dictionary of <type, object> where object is my various IService<T>?
Service lookup was built based on reading the DbContext code and simplifying the logic for DbContext.Set, which is also driven by IDictionary<Type, object>.
If through some kind of resolver parameter I can get all the IService<T>s, Extract the T types, and add them to that list, I'm off to the races.
Edit: I recognize I could inject the parameters I need to build each service
into ServiceLookup and manually build my list, and that may even be the better answer... but if I can do it without all that, it would be a lot more robust, and I'm fundamentally curious if it is possible
Edit2: What I want to be able to do in implementation would look like this:
public SomeController(IControllerServiceContext context, IServiceLookup lookup)
: base(context, service)
{
public SomeMethod() {
var x = lookup.Service<EntityOneDTO>().BuildProjections().FirstOrDefault();
var y = lookup.Service<EntityTwoDTO>().BuildProjections().FirstOrDefault();
//Do Logic that requires both EntityOne and EntityTwo
}
}
Let's assume you have the following types :
public class MessageA { }
public class MessageB { }
public interface IService<TMessage> { }
public class ServiceA : IService<MessageA> { }
public class ServiceB : IService<MessageB> { }
And you have a controller and you want to get a IService<MessageA> based on whatever you want.
The first solution would be to inject all IService you may required :
public class Controller
{
public Controller(IService<MessageA> serviceA, IService<MessageB> serviceB)
{
this._serviceA = serviceA;
this._serviceB = serviceB;
}
private readonly IService<MessageA> _serviceA;
private readonly IService<MessageB> _serviceB;
public void Do()
{
IService<MessageA> serviceA = this._serviceA;
}
}
It works if you have few message type but not if you have more than few.
because IService<T> is generic and Do there is no easy way to mix both world. The first solution would be to introduce a non generic interface
public interface IService { }
public interface IService<TMessage> : IService { }
and register these type like this :
builder.RegisterType<ServiceA>().As<IService<MessageA>>().As<IService>();
builder.RegisterType<ServiceB>().As<IService<MessageB>>().As<IService>();
Then you can have an IEnumerable<IService>. Something like that :
public interface IServiceLookup
{
IService<TMessage> Get<TMessage>();
}
public class ServiceLookup : IServiceLookup
{
public ServiceLookup(IEnumerable<IService> services)
{
this._services = services
.ToDictionary(s => s.GetType()
.GetInterfaces()
.First(i => i.IsGenericType
&& i.GetGenericTypeDefinition() == typeof(IService<>))
.GetGenericArguments()[0],
s => s);
}
private readonly Dictionary<Type, IService> _services;
public IService<TMessage> Get<TMessage>()
{
// you should check for type missing, etc.
return (IService<TMessage>)this._services[typeof(TMessage)];
}
}
and then inject IServiceLookup inside your controller.
The drawback of this solution is that it create instances of all your IService, to avoid that you can inject IEnumerable<Func<IService>>
Another solution would be to inject IComponentContext to ServiceLookup. ComponentContext is an Autofac type from where you can resolve services.
public class ServiceLookup : IServiceLookup
{
public ServiceLookup(IComponentContext context)
{
this._context = context;
}
private readonly IComponentContext _context;
public IService<TMessage> Get<TMessage>()
{
return this._context.Resolve<IService<TMessage>>();
}
}
Related
I have a class that returns a repository (read only) using a generic method this is to reduce the number of repository classes I need to inject into classes in my business layer. It also allows me to add and use a new repo anywhere I have this wrapper class simply by adding a repo which implements IGenericReadRepo<T> as this will be registered in unity using the line Container.RegisterType(typeof(IGenericReadRepository<>), typeof(GenericReadRepository<>), new TransientLifetimeManager());. However this has is dependent on unity being the DI container. This smells to me.
public class ReadRepositoryWrapper : IReadRepositoryWrapper
{
private IUnityContainer _unityContainer;
public ReadRepositoryWrapper(IUnityContainer container)
{
_unityContainer = container;
}
public IGenericReadRepository<T> GetReadRepository<T>() where T : class
{
return _unityContainer.Resolve<IGenericReadRepository<T>>();
}
}
Can anyone think of a way to implement the GetReadRepository<T> without a the dependency on unity while not introducing any new dependencies. Or can someone think of another way to get repositories without having bloated constructors or a dependency on my context.
You can create generic factory interfaces/classes for dynamic object creation. Many DI containers support object creation using lambda expressions.
public interface IFactory<T>
{
T Create();
}
public class Factory<T> : IFactory<T>
{
private readonly Func<T> _creator;
public Factory(Func<T> creator)
{
if(creator == null)
throw new ArgumentNullException("creator");
_creator = creator;
}
public T Create()
{
return _creator();
}
}
The generic factory interface than can be injected into the consuming classes.
public class ReadRepositoryWrapper<T> : IReadRepositoryWrapper<T> where T : class
{
private readonly IFactory<IGenericReadRepository<T>> _factory;
public ReadRepositoryWrapper(IFactory<IGenericReadRepository<T>> factory)
{
if(factory == null)
throw new ArgumentNullException("factory");
_factory = factory;
}
public IGenericReadRepository<T> GetReadRepository()
{
return _factory.Create();
}
}
Or something like that.
I am aware that this question has been asked many times. But looking at the answers I couldn't find the right one or working one that suits me.
Let's say I have an abstract class
public abstract class EntityService<T>
{
public T GetAll()
{
//Implementation
}
}
Then I have a drived class
public class UserService : EntityService<User>
{
public User GetAll(string Orderby)
{
//Implementation
}
}
And I create a static variable of the UserService for to use it through out my project.
public static readonly EntityService<User> UserService = new UserService();
Using UserService.GetAll(); would work perfectly fine. However when I want to use UserService.GetAll("Acsending"); would given an compiler error saying this method does not exist. I know I have to cast it to UserService Type but I couldn't do it. Where I put (UserService) It always gave errors and I am wondering is there a better way to do this without casting it since I want to write my code plain and simple as possible.
I think for your situation will be useful to do it like this, sorry that a little bit late, but:
public interface IUserService
{
User GetAll();
User GetAll(string OrderBy);
}
public abstract class EntityService<T>
{
public T GetAll()
{
//Implementation
}
}
public class UserService : EntityService<User>, IUserService
{
public User GetAll(string OrderBy)
{
//Implementation
}
}
And then use it like this:
public static readonly IUserService UserService = new UserService();
....
UserService.GetAll();
UserService.GetAll("orderByColumn");
And then if you want some common code for Entities, you can write something like this:
void ForEntityMethod(EntityService<T> entityService)
If special for Users i.e.:
void ForUserMethod(IUserService userService)
It think it give you more flexibility and avoid cast in your situation.
Also exist another good variants, but they are can be used if you have some future vision of system.
You need to either declare the variable as the subclass like this:
public static readonly UserService userService = new UserService();
Or, you downcast every time you want to use the EntityService<User> as UserService:
var userServiceDownCast = (UserService)userService;
userServiceDownCast.GetAll("Ascending");
These days I'm facing this situation often and I'm looking for an elegant solution. I have :
public abstract class TypeA
{
public abstract void AbtractMethod(IDependency dependency);
}
public class TypeB : TypeA
{
public override void AbtractMethod(ISpecializedDependencyForB dependency) { }
}
public class TypeC : TypeA
{
public override void AbtractMethod(ISpecializedDependencyForC dependency) { }
}
public interface IDependency { }
public interface ISpecializedDependencyForB : IDependency { }
public interface ISpecializedDependencyForC : IDependency { }
My objective is to make things transparent in the client perspective and to consume this code like that :
TypeA myDomainObject = database.TypeARepository.GetById(id); // The important point here is that I don't know if the object is of TypeB or TypeC when I consume it.
IDependency dependency = ? // How do I get the right dependency
myDomainObject.AbtractMethod(dependency);
So the thing is that since I don't know the concrete type of the object, I can't inject the right dependency into it.
What I'm currently doing is that I create an abstract factory, to inject the right properties. I have two problems with that, the first one is that I would end up with a lot of factories. The second one is that it makes polymorphism useless since the client actually needs to care about "managing" the underlying type (I need to inject all the possible dependencies in the factory, and to instantiate the factory on the client code).
1) Therefore I was thinking of using property injection with unity, but I can't find out if it's possible to resolve the dependencies of an object, after it's been instanciated manually. Even with this approach I think I could still meet the same problem : I'm not sure if unity would check the actual type of the object and resolve the right dependency if a syntax like this existed :
unityContainer.Resolve<TypeA>(myDomainObject)
If not, I would need to know the type in advance and would be back to the same problem.
2) I have found this article mentionning that EF provides some mechanism for DI, but it seems that it is only meant to inject the framework services (PluralizationService, etc...). Otherwise it would have been a nice way to achieve that.
3) I could also not use DI in this case... It looks like by concept DI does not fit well with polymorphism. I'm not excited by this idea though.
I'd be happy to have a solution for the property injection I'm trying to achieve, or an idea of pattern I could use. However I really don't want to create a big infrastructure and obfuscate my code just for this purpose.
Note : I don't want to you use domain events in this case.
Thank you
TL;DR
Replace the IDependency parameter of the polymorphic AbstractMethod with an implementation-specific construction dependency parameter, which is injected by the IoC container, not by the consumer.
In more detail
The original class hierarchy will need to look like more like this for inheritance polymorphicism to work, as the superclass virtual method and subclass override methods must match signatures:
public abstract class TypeA // superclass
{
public abstract void AbtractMethod(IDependency dependency);
}
public class TypeB : TypeA // subclass 1
{
public override void AbtractMethod(IDependency dependency)
{
Contract.Requires(dependency is ISpecializedDependencyForB);
// ...
}
}
public class TypeC : TypeA // subclass 2
{
public override void AbtractMethod(IDependency dependency)
{
Contract.Requires(dependency is ISpecializedDependencyForC)
// ...
}
}
However, some things don't ring true with this design:
The LSP appears to be violated, since the although AbtractMethod() advertises that it accepts the base IDependency interface, the two subclasses actually depend on a specialized subclassed dependency.
It is also unusual, and arguably inconvenient, for a caller of these methods to build up the correct dependency and pass it to the method in order for it to be invoked correctly.
So, if possible, I would adopt a more conventional approach to the arrangement of dependencies, whereby the dependency is passed to the subclass constructor, and will be available to the polymorphic method when needed. This decouples the need to supply the appropriate IDependency to the method. Leave it to the IoC container to do the appropriate dependency resolution:
Use constructor injection to create the correct dependency into Classes TypeB and TypeC
If there is a secondary requirement to Expose an IDependency on the base class TypeA to consumers, then add an additional abstract property to TypeA of type IDependency (but this seems iffy)
As per Ewan's observation, the repository would need some kind of strategy pattern in order to serve up polymorphic domain entities (B or C). In which case, couple the repository to a factory to do exactly this. The concrete factory would need to be bound to the container in order to tap into Resolve().
So putting this all together, you might wind up with something like this:
using System;
using System.Diagnostics;
using Microsoft.Practices.Unity;
namespace SO29233419
{
public interface IDependency { }
public interface ISpecializedDependencyForB : IDependency { }
public interface ISpecializedDependencyForC : IDependency { }
public class ConcreteDependencyForB : ISpecializedDependencyForB {};
public class ConcreteDependencyForC : ISpecializedDependencyForC { };
public abstract class TypeA
{
// Your polymorphic method
public abstract void AbtractMethod();
// Only exposing this for the purpose of demonstration
public abstract IDependency Dependency { get; }
}
public class TypeB : TypeA
{
private readonly ISpecializedDependencyForB _dependency;
public TypeB(ISpecializedDependencyForB dependency)
{
_dependency = dependency;
}
public override void AbtractMethod()
{
// Do stuff with ISpecializedDependencyForB without leaking the dependency to the caller
}
// You hopefully won't need this prop
public override IDependency Dependency
{
get { return _dependency; }
}
}
public class TypeC : TypeA
{
private readonly ISpecializedDependencyForC _dependency;
public TypeC(ISpecializedDependencyForC dependency)
{
_dependency = dependency;
}
public override void AbtractMethod()
{
// Do stuff with ISpecializedDependencyForC without leaking the dependency to the caller
}
public override IDependency Dependency
{
get { return _dependency; }
}
}
public interface ITypeAFactory
{
TypeA CreateInstance(Type typeOfA);
}
public class ConcreteTypeAFactory : ITypeAFactory
{
private readonly IUnityContainer _container;
public ConcreteTypeAFactory(IUnityContainer container)
{
_container = container;
}
public TypeA CreateInstance(Type typeOfA)
{
return _container.Resolve(typeOfA) as TypeA;
}
}
public class TypeARepository
{
private readonly ITypeAFactory _factory;
public TypeARepository(ITypeAFactory factory)
{
_factory = factory;
}
public TypeA GetById(int id)
{
// As per Ewan, some kind of Strategy Pattern.
// e.g. fetching a record from a database and use a discriminating column etc.
return (id%2 == 0)
? _factory.CreateInstance(typeof (TypeB))
: _factory.CreateInstance(typeof (TypeC));
// Set the properties of the TypeA from the database after creation?
}
}
class Program
{
static void Main(string[] args)
{
// Unity Bootstrapping
var myContainer = new UnityContainer();
myContainer.RegisterType<ISpecializedDependencyForB, ConcreteDependencyForB>();
myContainer.RegisterType<ISpecializedDependencyForC, ConcreteDependencyForC>();
myContainer.RegisterType(typeof(TypeB));
myContainer.RegisterType(typeof(TypeC));
var factory = new ConcreteTypeAFactory(myContainer);
myContainer.RegisterInstance(factory);
myContainer.RegisterType<TypeARepository>(new InjectionFactory(c => new TypeARepository(factory)));
// And finally, your client code.
// Obviously your actual client would use Dependency Injection, not Service Location
var repository = myContainer.Resolve<TypeARepository>();
var evenNumberIsB = repository.GetById(100);
Debug.Assert(evenNumberIsB is TypeB);
Debug.Assert(evenNumberIsB.Dependency is ISpecializedDependencyForB);
var oddNumberIsC = repository.GetById(101);
Debug.Assert(oddNumberIsC is TypeC);
Debug.Assert(oddNumberIsC.Dependency is ISpecializedDependencyForC);
}
}
}
Could whatever it is that knows about the dependencies live behind an interface IDependencyProvider which has a function
IDependency GetDependency(Type type).
This could even just return an object and the class that realises the interface needs to know all the sub types and their associated dependencies.
AbstractMethod is then changed to:
void AbstractMethod(IDependencyProvider provider);
In your sub classes you then override this and call
var dependency = provider.GetDependency(this.GetType());
Your middle tier then knows nothing about the sub types or the sub dependencies.
It's an interesting problem, what I was thinking is that your repository knows about and creates the TypeB and TypeC classes and so you can add the correct dependency at that point
public class TypeARepository
{
private ISpecializedDependencyForB depB;
private ISpecializedDependencyForC depC;
public TypeARepository(ISpecializedDependencyForB depB, ISpecializedDependencyForC depC)
{
this.depB = depB;
this.depC = depC;
}
public TypeA GetById(string id)
{
if (id == "B")
{
return new TypeB(depB);
}
else
{
return new TypeC(depC);
}
}
}
The TypeB and TypeC would then implement their abstract methods with their private ref to the dependency rather than having it passed in in the method.
I come across this problem in various forms myself from time to time and it always seems to me that if there is that hard link between the types just having it setup via an injection config or the like is wrong. As it allows the installer to potentially set a bad config
This approach also allows you to inject your dependencies with unity
Thank you a lot for your interest in my question, I came up with a solution yesterday evening. The objective is to keep things transparent for the client and to take full advantage of polymorphism by syntaxes such as baseObjectReference.AbstractMethodCall().
I finally realized that I was able to achieve what I'm after by taking advantage of the static modifier and using it for DI purposes. So I have that :
public abstract class TypeA
{
public abstract void AbtractMethod();
}
public class TypeB : TypeA
{
private ISpecializedDependencyForB SpecializedDependencyForB
{
get
{
return GetSpecializedDependencyForB.CreateSpecializedDependencyForB();
}
}
public override void AbtractMethod() { // do stuff with dependency }
}
public static class GetSpecializedDependencyForB
{
public static ISpecializedDependencyForB DependencyForB
{
return CreateSpecializedDependencyForB();
}
public delegate ISpecializedDependencyForB CreateSpecializedDependencyForBDelegate();
public static CreateSpecializedDependencyForBDelegate CreateSpecializedDependencyForB;
}
And then, in my unity container I add this code :
public static void RegisterTypes(IUnityContainer container)
{
// .... registrations are here as usual
GetSpecializedDependencyForB.CreateSpecializedDependencyForB = CreateMyDomainService;
}
Having this method in the same unity config class :
private ISpecializedDependencyForB CreateMyDomainService()
{
return container.Value.Resolve<ISpecializedDependencyForB>();
}
And finally, I can simply use my object like this :
TypeA myDomainObject = database.TypeARepository.GetById(id);
myDomainObject.AbtractMethod();
And that's it !
So four things here :
The first one is that I inject the delegate that will create and instance of the service.
Then it is thread safe because static member is only written one time at the beginning of the application. All other accesses will be read. Moreover two threads won't share the same instance of the dependency since the delegate creates a new one all the time.
Also one interesting thing is that I can rely on my existing unity container configuration, no extra code is needed. It is important because my dependency may need other dependency to be constructed.
And finally the unity container is anyway also static, so there is no memory leak.
It's basically a manual and easy to set up "DI framework" sitting beside Unity.
And more importantly it works like a charm ! I'm finally satisfied with my design. I will only use this approach for polymorphic situations since injecting the right dependency in the method is easy for other situations. However it might be interesting to fully encapsulate the domain model using this approach.
I am brand new to MEF and am stuck in "No parameterless constructor defined for this object" hell. I've looked at a lot of posts etc. over the last many hours and am totally stuck. What am I doing wrong? I'm using .NET 4.5, so do I still need all these attributes? Am I mixing older style MEF in with newer?
UPDATE:
The solution I'm working on also references Unity 3.3, so I think they may be stepping on each other. Do I need to remove Unity?
[Export]
[PartCreationPolicy(CreationPolicy.NonShared)]
public class HomeController : Controller
{
private readonly IHomeService _service;
[ImportingConstructor]
public HomeController(IHomeService service)
{
_service = service;
}
}
[Export(typeof(IHomeService))]
[PartCreationPolicy(CreationPolicy.NonShared)]
public class HomeService : IHomeService
{
private readonly IServiceSearch _serviceSearch;
[ImportingConstructor]
public HomeService(IServiceSearch serviceSearch)
{
_serviceSearch = serviceSearch;
}
}
[InheritedExport]
public interface IHomeService
{
// ...
}
[Export(typeof(IServiceSearch))]
[PartCreationPolicy(CreationPolicy.NonShared)]
public class ServiceSearch : DataHub.Search, IServiceSearch
{
[ImportingConstructor]
public ServiceSearch(IMapper<xxx, xxxDTO> x)
{
// ...
}
[InheritedExport]
public interface IMapper<TDomain,TDto>
{
TDomain ToDomain(object o);
void Initialize();
TDto DomainToDto(TDomain domain);
}
[Export(typeof(IMapper<Account, AccountDTO>))]
public class AccountMapper : IMapper<Account, AccountDTO>
{
//....
}
protected void Application_OnStart()
{
var catalog = new AssemblyCatalog(Assembly.GetExecutingAssembly());
var composition = new CompositionContainer(catalog);
IControllerFactory mefControllerFactory = new MefControllerFactory(composition); //Get Factory to be used
ControllerBuilder.Current.SetControllerFactory(mefControllerFactory);
}
public class MefControllerFactory : DefaultControllerFactory
{
private readonly CompositionContainer _container;
public MefControllerFactory(CompositionContainer container)
{
_container = container;
}
protected override IController GetControllerInstance(System.Web.Routing.RequestContext requestContext, Type controllerType)
{
Lazy<object, object> export = _container.GetExports(controllerType, null, null).FirstOrDefault();
return null == export
? base.GetControllerInstance(requestContext, controllerType)
: (IController)export.Value;
}
public override void ReleaseController(IController controller)
{
((IDisposable)controller).Dispose();
}
}
I managed to get your code working with these modifications:
Move the types nested inside ServiceSearch outside of it. I don't think that MEF supports nested types. (Looks as though this is just a typo in the code sample above. I don't think it was intended.)
Remove the InheritedExportAttribute from IMapper<,>. You have an explicit export on AccountMapper anyway. Without making this change, you end up with AccountMapper being exported twice. The import into ServiceSearch's constructor then fails because MEF doesn't know which of the two matching exports to use. Alternatively keep the InheritedExportAttribute and remove the explicit export.
Either remove the InheritedExportAttribute on IHomeService or the ExportAttribute on HomeService, for the same reason as above.
I'm just getting started with dependency injection. I've read the Ninject wiki and its very clear on how to inject dependencies where a single instance of the dependency is required, using constructor, property or method injection. But how do you handle the case where your class needs to construct objects during its lifetime (after construction)? For example:
class AddressBook
{
private List<IContact> _contacts;
public AddContact(string name)
{
_contacts.Add(****what?****)
}
}
The only way I can think is to use constructor injection to pass in an IKernel and use that to get our IContact:
class AddressBook
{
private IKernel _kernel;
private List<IContact> _contacts;
public AddressBook(IKernel kernel){ _kernel = kernel; }
public AddContact(string name)
{
_contacts.Add(_kernel.Get<IContact>(new Parameter("name", name)));
}
}
But then how can you actually inject the kernel? What mapping would be required? Is this even the right approach?
Thanks for any help
felix
Similar to what the others have answered, we use a generic IFactory interface:
public interface IFactory<T>
{
T Get();
}
Which can be used like this:
public AddressBook(IFactory<IContact> ContactFactory)
And then implemented like this:
public class InjectorFactory : IFactory<T>
{
// we wrapped the Kernel in an Injector class
public T Get() { return Injector.Get<T>(); }
}
And bound like this:
Bind(typeof(IFactory<>)).To(typeof(InjectorFactory<>))
It has worked very well for us so far.
The answer as suggested by Benjamin Podszun:
Inject a factory:
public interface IContactFactory
{
IContact CreateContact(string name);
}
class AddressBook
{
private IContactFactory _factory;
private List<IContact> _contacts;
public AddressBook(IContactFactory factory){ _factory = factory; }
public AddContact(string name)
{
_contacts.Add(_factory.CreateContact(name));
}
}
Then you can bind the factory to whatever you want to create any specific instance of IContact.
You can do it pretty cleanly with: (exec summary of another answer re a slightly different question)
Bind<Func<IContact>>().ToMethod( context => () => Kernel.Get<Contact>() );
Your other options are:
have an IKernel injected as you did (that's supported OOTB with any special tricks), but as you allude to, this is rarely what you want - that's tantamount to Service Location.
Do a full-scale factory. See the other answer for the idiomatic Ninject way (a provider) to do more or less what your answer-to-self says. You better have a good reason to do that amount of boiler plate though.