Mobile Framework for Mobile 5.0 - Resolving unmapped Interface returns null

Error Subclassing controls - workaround HERE

UPDATE: Mobile 6 Framework has an excellent DI container!   As of this writing you have to download it from the Source Code tab (it isn't in the release) but in the download they provlde performance test and the Mobile container out performs all others to include Unity.

http://mobile5framework.codeplex.com/  <= Mobile 5 Framework source code
http://www.codeplex.com/compactcontainer  <= Dependency Injection for Compact Framework 

Side note: one thing I really love about VSS, that we can't easily do in VSTS, is share projects between solutions.  For example, my production application (Electronic Patient Record Medical System) uses the same libraries as my Mobile 5 Framework (Codeplex) project.  So as I update/fix my framework it is immediately available for my codeplex project.  Even though my development environment is managed by VSS the interesting (cool/strange) thing is my Codeplex project is a VSTS solution that includes my shared VSS projects - and it doesn't complain - it works in both environments :)  

On to the real information:   I updated the CompactContainer today to return null if an interface is not Type Mapped, i.e., there is not an entry in the configuration file to support the type being resolved.

The alternative would be to throw an exception like other DI containers, which I trust a lot of thought went into.  I opted to return null for reasons demonstrated by the following code, e.g., if on line 37 my ILogger cannot be resolved (as it won't because it wasn't configured) line 38 will still result in a logger.

Why?  The Logger setter on line 24 set it to the value null, returned by Container.Resolve<ILogger>(), however line 20 sees the null which results in DefaultLogger() being instantiated and then returned on line 22. 

So the lazy instantiation of Logger ensures there will always be a logger HOWEVER if I did configure ILogger in my configuration file then it will be used.   Throwing Exceptions involve a performance hit which we really want to avoid in the Compact Framework.

NOTE:  I used .NET 3.5 extensions to substitute Resolve (on line 37 above) for the actual CompactContainer syntax shown on line 369 below.

My goal is to leave existing functionality of the CompactContainer intact, for backwards compatibility, while adding new features.   The image following this one shows the result(s) of unit test against the CompactContainer's original code.

The following shows the unit test using CompactContainer35 running against the original objects provided in the TestDI demo application (using it's config.xml and config2.xml contents):

Then of course we have our unit test for our new Interface injection: 

/// <summary>
/// Determines whether this instance [can inject interface with 
/// configured immplmentation].
/// </summary>
[TestMethod]
public void CanInjectInterfaceWithConfiguredImmplmentation()
{
    // ConfigFilename is pulled from the baseclass - it is
    // identical to the CompactContainer CONFIG.XML with used
    // with TestDI with exception of Filename and appended Properties
    CompactContainer.CompactConstructor.DefaultConstructor
        .AddDefinitions(ConfigFilename);
 
    // Resolve interface based on the following ObjectDefinition
    // in the configuration file (in AppBaseTest)
    //----------------------------------------------------------------------
    // <ObjectDefinition Name='TypeMappings'>
    //   <Property 
    //      Name='IMockDIObject' 
    //      SetWithNewType='CompactContainer.Tests.MockObjects.MockDIObject' 
    //      FileName='CompactContainer.Tests.dll'/>
    // </ObjectDefinition>
    //----------------------------------------------------------------------
    IMockDIObject mockObj = Container.Resolve<IMockDIObject>();
 
    // Assert that we successfully resolved our interface
    List<MockUser> userList = mockObj.GetUserList(this, EventArgs.Empty);
    Assert.AreEqual(2, userList.Count, "There should be two Mock Users");
    Assert.AreEqual("Bill", userList[0].FirstName);
    Assert.AreEqual("Diane", userList[1].FirstName);
 
}

Tags: , ,
Categories:


Actions: E-mail | Permalink |  Grammar/Typo/Better way? Please let me know