Multiple FactoryAttributes
Brian Chavez
Hi Philip,
Would it be possible to allow multiple FactoryAttributes on a class?
I currently have something similar to the following:
=========================================
[Factory(typeof(IUserAccountDao))]
[Factory(typeof(IUserRoleDao))]
AuthDaoFactory : IFactory<IUserAccountDao>, IFactory<IUserRoleDao>
{
.... code here to return Daos.... however, this code
constructs Dao's that work with one particular DB. All these
Daos here share the same datasource.
}
[Factory(typeof(IOtherDao))]
[Factory(typeof(IFooDao))]
OtherSourceDaoFactory : IFactory<IOtherDao>, IFactory<IFooDao>
{
.... code here returns Daos... however, this code
constructs Dao's that work with another DB other than the one
used in AuthDaoFactory... the Dao's here share the same
database connection string.
}
=========================================
Essentially, what I do next, is the following up at the higher level:
Repository.Resolve < IFooDao >().SomeOperation();
Repository.Resolve < IUserAccountDao >().CreateAccount("abc@abc");
Callers to Resolve() do not know what DaoFactory created the object, nor should the caller care. But, as it stands now, LinFu only allows me to attach one FactoryAttribute to the Factory objects.... this means, I need to add a new factory for each new Dao I create (which I don't want).
Are there any other solutions or workarounds that could solve this issue more elegantly? Or, perhaps, my architecture is whacked. :-/
Many thanks,
Brian
----------------------------------------------
Brian Chavez
Bit Armory, Inc.
http://www.bitarmory.com
Philip Laureano
As it turns out, Simple.IoC supports multiple FactoryAttributes "out of the box", so to speak. All I had to do was change this line of code:
[AttributeUsage(AttributeTargets.Class, AllowMultiple=false)]
to:
[AttributeUsage(AttributeTargets.Class, AllowMultiple=true)]
...and that should give you the multiple FactoryAttribute support you're looking for. The only thing that you have to keep in mind is that the Simple.IoC Loader will actually create a single instance per FactoryAttribute, so for example, if you're using two FactoryAttribute declarations on a single custom factory type, the loader will actually create two instances--one for the first FactoryAttribute declaration, and another for the second FactoryAttribute declaration. This setup should work, provided that you don't expect to swap data between two different instances of the same custom factory type. If you absolutely need to share state between two instances of an AuthDaoFactory, you can probably encapsulate the changes in an external (hypothetical) ICommonStateOrSettings implementation of your own, and you can use the container itself to hold those common settings between factories.
In any case, go ahead and try using the latest revision (rev 135) with the multiple factory attribute support, and if you run into any problems, I'll see what else I can do to help you. HTH :)
Regards,
Philip Laureano
Brian Chavez
Hi Philip,
Thanks for the update!
However, I'm not too sure if I like the idea of multiple factory objects being alive in memory, because, architecturally from my point of view it wasn't my intention. And a small detail like this could easily slip through the cracks if it isn't properly documented. (and we know nobody reads the documentation! :P haha)
It would mean, N Daos and N Factory objects. In a system with 25 Daos, 25 Factory objects isn't a big deal, but in my opinion, it isn't the way I had intended my architecture to be designed. Ultimately, my architecture is influenced by LinFu FactoryAttribute details and the way FactoryAttribute is handled which could cause problems later.
After thinking about it a little more, I think my problem is a design flaw in my architecture, because, later, if I decided to add a new Dao, I would need to add a new FactoryAttribute on the factory class + add the new IFactory<IDao> to the factory class extension list which is a two step process. The down side is, if AuthDaoFactory handles the construction of 25 Daos, I would have something like:
[25 Factory Attributes]
AuthDaoFactory: 25 IFactory<IDao>
which doesn't help readability or maintainability.
So, I think I'm going to need to restructure a few things so I could something like:
AuthDaoFactory{
Initialize(){
this.AddHandledType( typeof(IUserAccountDao) );
this.AddHandledType( typeof(IUserRoleDao) );
...etc.
}
}
It's probably a better solution in the long run. Thanks again Philip for all your help. I'm still using LinFu in a lot of places, and it's working out well so far. I really love the ContainerPlugin extensibility points. They were a perfect fit for loading custom SectonHandler information per library. It's awesome.
Thanks again Philip.
-Brian
----------------------------------------------
Brian Chavez
Bit Armory, Inc.
http://www.bitarmory.com
Philip Laureano
I'm glad I can help. It sounds like you've got a bit of a Strategy pattern problem with your architecture! In any case, I've patched Simple.IoC (revision 136) so that you'll only get one object instance for each implemented custom factory class type. For example, if I have a custom factory declared as:
[Factory(typeof(IFoo))]
[Factory(typeof(IBar))]
public class BarFooFactory : IFactory<IFoo>, IFactory<IBar>
{
// ...
}
...the loader itself will only create one instance of BarFooFactory, despite the fact that you have more than one FactoryAttribute declared on that class. That should take care of any state problems you might have when dealing with custom factories that create multiple types of objects.
Enjoy!