Ninject auto binding

This is called scan by convention in StructureMap, I’m surprised it’s not in standard Ninject package, while this feature call be found in Ninject.extension.conventions.

OK, let go get it. git clone, compile failed due to whole bunch of silverlight stuff. Weird, I gave up, time to try the powerful NuGet.

I would say NuGet is amazing, dependency lookup just like gem in ruby, libs are downloaded into packages folder.? OK, anyway, move it after if you don’t like it.

How to get the history version from NuGet?

One frustrated thing in VisualStduio is, the version number in project file (csproj) still keeps untouched, the problem turned to compile passed, but unit-test running into an error, can not find the assembly in old version.

Old version is not in GAC, I had to change those out-of-date csproj manually, the problem went away. VisualStudio Bug?

Ninject auto binding code:

            var standardKernel = new StandardKernel();

            // Manually set bind for those classes not folowing convention
            standardKernel.Bind().ToSelf();
            standardKernel.Bind().To();

            standardKernel.Scan(x =>
                {
                    x.FromAssembliesMatching("*");
                    x.BindWith();
                });

About generic:

For closing generic implementation like EmailRepository : IRepository<Email>, we can use

a.BindWith(new GenericBindingGenerator(typeof(IRepsitory<>)));

Even more advanced, check  this post about multi generic binding.

For open generic (Jeremy Miller is not recommanding this approach though.) like Repository<Email> : IRepository<Email>, the trick is:

Bind(typeof(IRepository<>).To(typeof(Repository<>)).

Handle Dependency in NServiceBus

I was using poor-man’s injection in NServiceBus until this morning I figured out how to handle dependency in NServiceBus. It’s easy, but I never got chance or brave enough to try it out

NServiceBus uses SpringBuilder as default. I want to stick with StructureMap.

Here is official doc for how to wire StructureMap up with NServiceBus: http://sourceforge.net/apps/mediawiki/nservicebus/index.php?title=Additional_containers

    // Default
//    public class EndpointConfig : IConfigureThisEndpoint, AsA_Server
//    {
//    }
    public class EndpointConfigUsingStructuremap : IConfigureThisEndpoint, AsA_Server, IWantCustomInitialization
    {
        #region IWantCustomInitialization Members

        public void Init()
        {
            Configure.With()
                .StructureMapBuilder(new Container(new DependencyRegistry()))
                .XmlSerializer();

            // you can leave the rest of the config off since "AsA_Server" handles it
        }

        #endregion
    }

    public class DependencyRegistry : Registry
    {
        public DependencyRegistry()
        {
            // Manually set
//            For<IFileService>().Use<FileService>();

            // Or auto scan
            Scan(x =>
            {
                x.TheCallingAssembly();
                x.AssemblyContainingType<IFileService>();
                x.WithDefaultConventions();
            });

        }

    }

 public class DbChangeHandler : IMessageHandler<DatabaseChangedCommand>
    {
        private readonly IFileService _fileService;

        public DbChangeHandler(IFileService fileService)
        {
            _fileService = fileService;
        }

        public void Handle(DatabaseChangedCommand message)
        {
         ...
// My old syntax, poor-man/static injection.
//            FileService.TouchFile(message.DatabaseName, path);
            _fileService.TouchFile(message.DatabaseName, path);
        }
    }

Amazing!

Another team from our company is using Ninject which is not in the out-of-box container list supported by NServiceBus (yet) , google found a solution by Aaron Jenson, https://github.com/aaronjensen/nservicebus.objectbuilder.ninject I will get there soon.

Updated on Mar. 11, 2011:

This code from https://gist.github.com/326321 works in Ninject 2.2 and NServiceBus 2.

public class EndpointConfig : IConfigureThisEndpoint, AsA_Server, IWantCustomInitialization
    {
        #region IWantCustomInitialization Members

        public void Init()
        {
            Configure.With()
                .Log4Net<ConsoleAppender>(x => { x.Threshold = Level.Info; }
                ).Log4Net<FileAppender>(x =>
                {
                    x.File = "build_trigger_log.txt";
                    x.Threshold = Level.Info;
                }
                )
                .NinjectBuilder()
                .XmlSerializer();

            // you can leave the rest of the config off since "AsA_Server" handles it
        }

        #endregion
    }

internal class CustomModule : NinjectModule
    {
        public override void Load()
        {
            Bind<IFileService>().To<FileService>();
        }
    }

// NinjectObjectBuilder is from https://gist.github.com/326321
    public static class ConfigureNinjectBuilder
    {
        public static Configure NinjectBuilder(this Configure config)
        {
            ConfigureCommon.With(config, new NinjectObjectBuilder(new StandardKernel(new CustomModule())));
            return config;
        }
    }

Note:

1. If using NServiceBus Testing framework, constructor inject might not work, should use setter inject instead.
2. When using autobinding in Ninject, there is a conflict in IMessageSerliazer class, my quick workaround is providing the sample type instead of ScanAssemblyMatch(‘*”), or use Scan WithoutNamespaceOf(“NServiceBus”) to allow NSB use it’s own autobinding on Msmq stuff.
3. NSB supports both ctor injection and setter injection, but NSB.Testing framework need a default no-arg ctor, so setter injection is the only choice if using NSB.Testing.

 [TestFixture]
    public class DbChangeHandlerTest
    {
        [SetUp]
        public void Setup()
        {
            mockFileService = MockRepository.GenerateMock<IFileService>();

            Test.Initialize();

            systemUnderTest = Test.Handler<DbChangeHandler>()
                .WithExternalDependencies(h => h.file_service = mockFileService);
        }

        IFileService mockFileService;
        Handler<DbChangeHandler> systemUnderTest;

        [Test]
        public void should_call_file_service_to_touch_file()
        {
            systemUnderTest
                .OnMessage<DatabaseChangedCommand>(m => m.DatabaseName = "");

            mockFileService.AssertWasCalled(x => x.TouchFile("", ""), opt => opt.IgnoreArguments());
        }

        [Test]
        public void should_response_to_database_changed_command()
        {
            systemUnderTest
                .OnMessage<DatabaseChangedCommand>(m => m.DatabaseName = "");
        }

        [Test]
        public void should_return_error_code_zero()
        {
            systemUnderTest
                .ExpectReturn(errCode => errCode == 0)
                .OnMessage<DatabaseChangedCommand>(m => m.DatabaseName = "");
        }
    }

IOC in WPF/WCF

It makes sense to take advantage of IOC in WCF, because all WCF services are parallel, and usually WCF service suppose to behave like a wrapper to Domain service which might needs a repository which needs an NHibernate session… How to new up those dependencies? IOC is the easiest way. And it becomes the new evil global.

In WPF, we’ve already got an un-avoidable global main window, or shell view in MVVM. Adding IOC just introduces more overhead. Even further Caliburn.Micro framework forces developer to implement a bootstrapper acting as the wrapper to the actual IOC container, the only dependency in this bootstrapper is the shell view model. If your shell view model has dependencies, you need to set them up in your underlying container. To me, this is a chicken-egg question.

 public class StructureMapBootstrapper : Bootstrapper<IShellViewModel>
    {

        protected override void Configure()
        {
            ObjectFactory.Initialize(x => x.AddRegistry<WpfDependencyRegistry>());
        }

        protected override object GetInstance(System.Type service, string key)
        {
            return ObjectFactory.GetInstance(service);
        }

    }

// StructureMap is not available in Silverlight yet, use SimplerCotainer from Caliburn instead in SL
   public class SilverlightBootstrapper : Bootstrapper<IShellViewModel>
    {
        private SimpleContainer _container;

        protected override void Configure()
        {
            _container = new SimpleContainer();

            _container.RegisterSingleton(typeof(IMessageBox), null, typeof(SlMessageBox));
            _container.RegisterSingleton(typeof(IProductSearchTask), null, typeof(ProductSearchTask));
            _container.RegisterSingleton(typeof(IProductCrudTask), null, typeof(ProductCrudTask));

            _container.RegisterSingleton(typeof(IShellViewModel), null, typeof(ShellViewModel));

        }

        protected override object GetInstance(Type service, string key)
        {
            return _container.GetInstance(service, key);
        }
    }

A better solution might be to use poor man injection in shell view model to new up all the dependencies in it’s no-arg ctor. This will remove any IOC usuage from WPF/Silverlight project, so UI developer can relief from framework hassle, and concentrate on their spinning button work.

MEF in MVVM

I read a post about MEF vs. IOC which cleared the confusion: MEF should be used external of app, while IOC should be used internally.

Good point. I have been struggling with how to separate my view and view model correctly in WPF app for a long time.   In fact Bil Simer already suggested that MEF is perfect fit in MVVM/Presentation Model last year during the Edmonton Code Camp 2008.

Ideally, all view models can be compiled into a separated assembly and put into specific folder to be imported by UI views!

Some code changes during my code conversion include:

• Remove ctor args from view model, I haven’t figure out how to feed ctor args when MEF importing. This is not easy as auto-wiring in IOC. I ended up with a separate initialize method in each view model, which is not too bad, because I have to call wireUpViewModel from view anyway, this Initialize method has a perfect place to put.
• I’m still not sure where should I put Container.Compose() method, because this method needs the instance the object to be imported into, I think compose as needed is better for WPF app.
• Shared mode is the default behavior for export and import, it messed up my event handling code, (true, I didn’t do -= before +=). I had to explicitly add this everywhere.
• AllowRecomposition is a pain for me, couldn’t get it work at all. I have tried many different ways to create a second instance of the exported class. PartCreationPolicy? AllowRecomposition attribute? Maybe because I’m working on a beta version?   Recomposition doesn’t work in contrustor paramteters, see Glen’s post.
• Too many attributes kinds of pollute my code. Adding those export/import attributes just like playing ping-pong. If you are not good at it, you become dizzy very quickly.
  

  [Export]
  [PartCreationPolicy(CreationPolicy.NonShared)]
  
  [Import(typeof(NewRequestTypeViewModel), RequiredCreationPolicy = CreationPolicy.NonShared)]
  
  [ImportingConstructor]
  
  [Import(AllowRecomposition=true)] //this can apply directly on ctor parameters, but recompositorion won't work in ctor (for now)

• I still feel using StructureMap to hookup viewmodel inside view is better and more comfortable. Even this violates some principals,  but in shell to open the view is much simpler, just new view(). ViewModel should sit behind the view, those UI developers/designers shouldn’t be ware of the exist of any view modles.

public RequestDetailsView(RequestDto requestDto)
{
  InitializeComponent();
  _viewModel = ObjectFactory.With("requestDto").EqualTo(requestDto).GetInstance<MyViewModel>();
  DataContext = _viewModel;
}

Make WCF client/proxy IOCable

For unit-test purpose, it’s necessary to make WCF client/proxy class implement from an interface.

The problem is, we suppose to clean up this WCF client after each service call, which means it should be able to repeatedly contracted and disposed. From IOC container we can only get it once. A factory for WCF client is the only solution.

There is an OSS lib from SoftwareIsHardwork. Very detail document.

I personally like Michael Perry’s POCO better:  Client object is created and closed in each service method call, and method is wrapped in lambda expression, very clean and smart.

Using StructureMap to mock DataAccess in CSLA BO

I had always thought StructureMap is just another IOC tool similar to Castle windsor, until yesterday I read Karl Seguin’s Foundations of Programming, Chapter 4, I was shocked immediately by the injectStub method provided by StructureMap, which is now renamed to inject(). I think this explicitly injection is better than TypeMock implicitly mock instance object.

For example, I have an Organization BO,

public static OrganizationBO GetOrganizationBO(int Id)
{
return DataPortal.Fetch<OrganizationBO>(new SingleCriteria<OrganizationBO, int>(Id));
}

private void DataPortal_Fetch(SingleCriteria<OrganizationBO, int> criteria)
{
OrganizationDTO data = DataAccess.OrganizationRepository().FindById(criteria.Value);

if (data != null)
{
LoadFromDTO(data);
}
}

The repository is declared in DataAccess class to centralize all the dataaccess coupling inside CALS BOs.

public static IRepository<OrganizationDTO> OrganizationRepository()
{

// instead of direct coupling return new OrganizationRepository();
// I use StrcutureMap
return ObjectFactory.GetInstance<IRepository<OrganizationDTO>>();
}

The content of IOC config file:

<DefaultInstance
PluginType=”DemoApp.Data.Interfaces.IRepository`1,DemoApp.Data”    PluggedType=”DemoApp.Data.Repository.OrganizationRepository,DemoApp.Data”
/>

We can also use other different ways to set dependency, like setDefault in code, or search assembly at  runtime as shown in this post.

Test  code:

[Test]
public void CanGetFromInjectedMockRepository()
{
var mockRepository = new Moq.Mock<IRepository<OrganizationDTO>>();

// Id in MoQ matters. But TypeMock doesn't care.
mockRepository.Expect(x => x.FindById(8172)).Returns(
new OrganizationDTO
{
Id = 1,
Name = "A test org name"
});

ObjectFactory.Inject(typeof(IRepository<OrganizationDTO>), mockRepository.Object);

var o = OrganizationBO.GetOrganizationBO(8172);

Assert.AreEqual(1, o.Id);
Assert.AreEqual("A test org name", o.Name);
}

Here is an artile introducing StructureMap, as it mentioned, StrucutreMap is very good choice if you are working on a class has no “constructor injection”, CSLA is one of those!

I have the same feeling, as the author Karl Seguin said, constructor injection doesn’t really solve the extensibility problem; how does someone add(try to replace) a new plug-in without recompiling the entire application?

The problem/drawback to DI is also obvious, the xml config file keeps growing and expanding. The performance and mantiance will become an issue. That’s why Boo was inverted to save / speed up Castle Windsor. But what about structure Map?

Also I need tool / method to test this xml config file, see details here and here. Unfortunately, I couldn’t make this <structuremap.verification> task loaded into NAnt, (maybe this doesn’t exist in those two dlls at all? I can’t tell because NAnt loadTask doesn’t have output). I tried to different folders and also “Forced scan” using <loadtasks> command, neither one works. Thanks God, Jeremy does have another way to test config file,so called smock test:

ObjectFactory.AssertConfigurationIsValid();

Regarding unit-test and mock, I spent a lot time trying to figure out how to reset the default back. It turns out the documented ObjectFactory.resetdefault has been changed to reset.

TypeMock Repository object in CSLA BO

CSLAEx DAL’s basic idea is adding an middle method in DataPortal_XXX():

CSLA BO Get -> DataPortal_Fetch -> DataAccess.ReadDataMethod (return SafeDataReader)

I added another repository in between to introduce stong type domain object instead of DataReader (I think DataReader is not much difference than DataSet in UI)

CSLA BO Get -> DataPortal_Fetch ->Repository.DataProssingMethod() (return DTO)-> DataAccess.ReadDataMethod (return SafeDataReader)

Repository can be mocked, and DataAccess can be tested (based on peeking into db then writing assert expection.)

The next problem is, how to test / mock the top level static Get method? I tried using adapter pattern by adding a injectable public constructor to BO, then the test case code like this:

[Test]
public void GetProductOnBOTestUsingMock()
{
MockRepository mocks = new MockRepository();
IProductRepository mockRepository = (IProductRepository)mocks.CreateMock<IProductRepository>();
Product p = new Product(mockRepository);
Guid id = Guid.NewGuid();
using (mocks.Record())
{
ProductDTO fakeProduct = null;
Expect.Call(mockRepository.GetById(id)).Return(fakeProduct);

}// Replay and validate interaction
Product obj = null;
using (mocks.Playback())
{
obj = p.GetProductAdaptor(id);

}// Post-interaction assertions
Assert.IsNull(obj);

Assert.AreEqual(obj.ProductName, "");
}

This test case failed, because in CSLA’s calling sequence:

Client.DataPortal -> LocalProxy -> Server.DataPortal -> 1. ServicedDataPortal TransactionalTypes.EnterpriseServices: 2. TransactionalTypes TransactionalTypes.TransactionScope 3. SimpleDataPortal default

The last step will run this piece of code:

namespace Csla.Server
{

public class SimpleDataPortal : IDataPortalServer
{
public DataPortalResult Fetch(Type objectType, object criteria, DataPortalContext context)
{
object obj = null;
try
{
// create an instance of the business object.
obj = Activator.CreateInstance(objectType, true);
...

My attempt to adding constuctor injection won’t suceed. I had to back to TypeMock then:

[Test]
public void TestGetUsingTypeMock()
{
// Setup Stud Data
ProductDTO stubProdDTO = new ProductDTO();
stubProdDTO.ProductName = "TypeMocked prod name";

// Everything inside recorder block will be mocked.
// expect the last line settng return value.
using (RecordExpectations recorder = RecorderManager.StartRecording())
{
ProductRepository mockRepository = new ProductRepository();
mockRepository.GetById(Guid.Empty);
recorder.Return(stubProdDTO);
}

Product p = Product.GetProduct(Guid.Empty);
Assert.IsNotNull(p);
Assert.AreEqual("TypeMocked prod name", p.ProductName);
}

It’s green

Another benefit to add a repository between BO and DataAccess object might be, it will be easier to use Castle’s IIntercepter to log those repository calls. As Castle warned:

If you are registering a component without an interface (the service) then only virtual methods can be intercepted.

Miguel seems doesn’t like code against interface in his dataaccess class, neither does Rocky in his CSLA BO. But we can add interface in our repository object. I am going to post this part of code once I finish it.

About repository class, JP treats those classes as DataAccess objects which makes sense, the return type of his repository class is Domain object, so he convert those domain object to DTO in his task layer using mapper class (Martin Fowler initially uses XXXAssembly class to do the conversion between domain object and DTO) Our CSLA BO is too rich which can not be returned from repository, so my repository just returns DTO instead. I think this solution can eliminate the usage of task and mapper object in my project.

IOC Container in CSLA

First, we need to create a IocContainer with a static field IWindsorContainer, this idea is from Steven Rockarts. I added a setter to container property, which will make my later unit-test live much easier. The reason is, CSLA does not implement DI (Datacontext or datarepository is hidden in BO base object).

Somewhere in my application’s initialize period, I should do IocContainer init, do does my unit test setup.

IocContainer.Container = new WindsorContainer(new XmlInterpreter(new ConfigResource(“castle”)));

The new CSLA BO’s dataaccess functions look like this:

public static Trainee GetTrainee(int traineeId)
{
return GetTrainee(traineeId, IocContainer.Container.Resolve<ITraineeRepository>());
}

public static Trainee GetTrainee(int traineeId, ITraineeRepository dtx)

In my test, create 2 mock repository classes:

class TraineeRepositoryMock : ITraineeRepository
{
public SerializableEntity<DalLinq.Trainee> GetTrainee(int id)
{
Gain.DalLinq.Trainee t = new Gain.DalLinq.Trainee();
t.Given_Names = “FFFFF”;
SerializableEntity<Gain.DalLinq.Trainee> st = new SerializableEntity<DalLinq.Trainee>(t);
return st;
}

public virtual int SaveTrainee(DalLinq.Trainee obj, DalLinq.Trainee original)
{
Console.WriteLine(“Hi, fake normal update!”);
return 0;
}
}

class TraineeRepositoryMockFalseUpdate : TraineeRepositoryMock
{

override public int SaveTrainee(DalLinq.Trainee obj, DalLinq.Trainee original)
{
Console.WriteLine(“Hi, false update!”);
return -1122;
}
}

The second one is to created to test the update failure exception handling.

The castle config file:

<configSections>
<section name=”castle”
type=”Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor” />
<section name=”cc2″
type=”Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor” />
</configSections>

<castle>
<components>
<component id=”traineeRepositoryMock” type=”Gain.Library.Test.TraineeRepositoryMock, Gain.Library.Test”
service=”Gain.DalLinq.ITraineeRepository, Gain.DalLinq” />
</components>
</castle>

<cc2>
<components>
<component id=”traineeRepositoryMockFalseUpdate” type=”Gain.Library.Test.TraineeRepositoryMockFalseUpdate, Gain.Library.Test”
service=”Gain.DalLinq.ITraineeRepository, Gain.DalLinq” />
</components>
</cc2>

The whole unit-test:

[TestFixture]
public class TraineeDATestMock
{

[SetUp]
public void SetUp()
{

IocContainer.Container = new WindsorContainer(new XmlInterpreter(new ConfigResource(“castle”)));

}
[Test]
public void CanGetTraineeTroughMockRepository()
{
Trainee item = Trainee.GetTrainee(2);
Assert.AreEqual(“FFFFF”, item.GivenNames);
}

[Test]
[ExpectedException(typeof(DataPortalException))]
public void CanCatchUpdateTraineeException()
{

// use the new IocContainer to read those false update mock repository.
IocContainer.Container = new WindsorContainer(new XmlInterpreter(new ConfigResource(“cc2”)));

Trainee oldTrainee = Trainee.GetTrainee(2);
oldTrainee.GivenNames = “BBBB”;
oldTrainee.Save();

}

[Test]
public void CanUpdateTrainee()
{

Trainee oldTrainee = Trainee.GetTrainee(2);

oldTrainee.GivenNames = “AAAA”;
Trainee newTrainee = oldTrainee.Save();
Assert.AreEqual(“AAAA”, newTrainee.GivenNames);

}
}

I think this way of unit-test CSLA BO is clearer than TypeMock. We should try to avoid to use TypeMock, unless you are testing a legacy app, as Billy McCaffery pointed out:

a tool such as TypeMock should be used only when absolutely necessary as it can lead to habits of not programming-to-interface.

In fact, those ‘Mock’ objects I created should be called stub. A stub is a class that is hard-coded to return data from its methods and properties. Thanks to Jeremy Miller for clarification.

My question is, becuase TypeMock doesn’t work with castle windsor container, can I use Rhino Mock to mock this internal/private Repository object instead of using stub + switching different castle config file?

Why AOP?

AOP, Aspect Oriented Programing, we need it because we want to do logging, security, and all those crosscutting concerns in the right way.

Business Objects, or domain object should not involved those because they should be clean and simple. Those crosscutting concerns can be injected into, by introducing AOP, through Castle Windsor Container, creating an object implementing IInterceptor interface, then inject it into the target BO by changing configuration file. Example can be found at Matthew’s old blog, and new blog.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <components>
    <component id="repository"
               service="WindsorInterceptor.IRepository`1, WindsorInterceptor"
               type="WindsorInterceptor.Repository`1, WindsorInterceptor">
      <interceptors>
        <interceptor>${logInterceptor}</interceptor>
      </interceptors>
    </component>
    <component id="logInterceptor"
               service="WindsorInterceptor.ConsoleLogInterceptor, WindsorInterceptor"
               type="WindsorInterceptor.ConsoleLogInterceptor, WindsorInterceptor"
               lifestyle="transient">
    </component>
  </components>
</configuration>

Rethinking Constructor parameters

Martin Fowler marked in his book Refactoring, try to use object as method parameter instead of variable.

Yesterday, after hours of unable making constructor with parameters working in Windsor container, I realized the constructor of my component needs change, using component as parameter, then Castle Windsor container’s auto-wiring just works fine.

To make variable parameter work, as mentioned in this post, I added a #{parameter_name} in to component’s parameter attribute, but I had to add a fake properties section in config file to launch the application, then by sing hastable passing parameter value, the component construct without any problem. The thing is, Windsor is too smart in this case, it always tries auto-wire one of my construct event to a null object. I had to remove the multiple construct method in my component.