We develop our applications in a modular fashion from our presentation assemblies down to our DAL assemblies. This, unfortunately, has led us to notice a small problem when dealing with the ObjectFactoryLoader found in FactoryImplementation in CSLA 4.1. The issue is that the ObjectFactoryLoader assumes that there is only one active DAL assembly, which is not suitable for our situation as we can have many.
What we figured would be best was that the ObjectFactoryAttribute had an extra parameter in which we could specify the key we would like to get from the configuration file. But that would require us to modify the class and introduce something we'd need to handle in future version of CSLA.
Does someone have a better solution for this type of situation?
If you create your own object factory loader you can do anything you want. There's nothing that prevents you from loading different (or multiple) DAL assemblies based on your requirements.
The Using CSLA 4: Data Access ebook shows how to create a custom factory loader.
The default factory loader interprets the ObjectFactory attribute's factory name parameter as an assembly qualified type name. But that factory name parameter is just a string, and so it can contain anything you want - if you create a custom factory loader to interpret that value differently.
For example, you could devise a different convention for the name string, such as:
Your custom factory loader will get this string, and can parse and use it however you'd like. A simple string split will give you the two parts of the value, and you can use "ConfigFileKey" to do your config file lookup to find the assembly, and then use the "DalTypeName" to find the class within that assembly - or whatever else you can think of doing.
You could also create an interface for all your "root" object factories and use:
and your own ObjectFactoryLoader with an IOC container to resolve the interface to a new actual instance of the root factory.
Copyright (c) Marimer LLC