I don't understand why the ParseDomain() is called before all assemblies are loaded, but OK, commit.The idea I had in mind when writing this class was that I would replace it in a real-world project by a real dependencies injection, such as Spring.NET. But at second thought, I'm not sure anyone will use the loose coupling from DbLinq, so it may even be removed and replaced by direct instantiation.
Pascal. jabber/gtalk: [email protected] msn: [email protected] On Sat, Mar 28, 2009 at 04:31, Jonathan Pryor <[email protected]> wrote: > ReflectionObjectFactory is too magical, and it's causing unit tests to > fail. > > Specifically, I ran across this "joy" recently, and took me until now to > diagnose: The DbMetal_test.dll tests run without error if you load *only* > DbMetal_test.dll into NUnit. > > If, however, you instead use the DbLinq.nunit project file (which lists * > all* NUnit test assemblies), then the GetWordsTest_MyTableName, > GetWordsTest_MyTableName2, and InvalidCharctersLanguage2Test tests within > NameFormatterTest (in DbMetal_test.dll) all fail with a > NullReferenceException. Oops. > > Why? Because within DbLinq.nunit the DbMetal_test.dll assembly is listed > *last*. Consequently, it (apparently) isn't loaded within the AppDomain > when ReflectionObjectFactory.ParseAppDomain() is executed, and thus > important types located within DbMetal.exe (such as > DbMetal.Language.EnglishWords) aren't found. > > Furthermore, it *is* an ordering issue -- if I alter DbLinq.nunit so that > DbMetal_test.dll is loaded *first*, then all the NameFormatterTest tests * > pass*. > > So, there's an obvious (in hindsight) ordering dependency here, which > raises the question: what should be done about it? > > The simple solution is to say this is By Design, and change DbLinq.nunitso > that > DbMetal_test.dll is done first. > > I don't like this idea as it's borderline evil. (It also means assembly > names can't be sorted, making it harder for me to make sure that all test > assemblies are actually listed within DbLinq.nunit.) > > What I don't know about is a "proper" solution. Previously I've mentioned > using assembly-level attributes (as they're faster), but that won't work > here as the assembly needs to be loaded in order for attributes to be a > viable solution, and in this case the assembly isn't loaded. > > My current idea, which I'd appreciate feedback on, is to modify the > DbLinq.Factory.IObjectFactory interface to add Register() and > Unregister()methods [0]: > > interface IObjectFactory { > void Register(Type implementationType); > void Unregister(Type implementationType); > // ... > } > > These methods would allow NameFormatterTest to ensure that the > appropriate types could be found, e.g. within GetWordsTest_MyTableName: > > try { > ObjectFactory.Current.Register(typeof(EnglishWords)); > // ... > } > finally { > ObjectFactory.Current.Unregister(typeof(EnglishWords)); > } > > Attached is a patch which implements this idea, and allows the > DbMetal_test.dll unit tests to work without ordering dependencies. (The > patch also implements the ideas in [0].) > > Permission to commit? > > Thanks, > > - Jon > > [0] I'm not entirely fond of the IObjectFactory interface, because it has > duplication, e.g. Get<T>() and GetInstance() do the same thing, and > Create<T>() and GetInstance() also do the same thing. Furthermore, using > a bool to choose between Get and Create is counter to FxDG, as it makes > the callsite unobvious (does true mean get or create semantics?). > > Consequently, in the attached patch I altered IObjectFactory to be: > > interface IObjectFactory { > void Register(Type implementationType); > void Unregister(Type implementationType); > object Create(Type interfaceType); > object Get(Type interfaceType); > IEnumerable<Type> GetImplementations(Type interfaceType); > } > > To preserve the generic niceties of the original Get<T>() and related > methods, I've added an ObjectFactoryExtensions class which provides > extension methods to implement Create<T>() and Get<T>() in terms of > IObjectFactory. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
