Comments on: AutoMapper DSL design post-mortem

By: bogardj

bogardj — Thu, 07 Jan 2010 13:20:03 +0000

@Betty

As it is right now, you don’t need static objects. The Mapper static class is merely a wrapper around the configuration/engine objects that do the real work.

By: Betty

Betty — Thu, 07 Jan 2010 03:16:04 +0000

I’m a fan of creating a class for each mapping, meaning i’d love something like.

public class MappingClass1 : Mapping {
public override CreateMapping() {
Map(s => s.Property, d => d.Property);
Map(s => s.Property2, d = d.Property2);
}
}

Which then get registered to a AutoMapper Profile

new AutoMapperConfig() { new MappingClass1(), new MappingClass2() };

I could then use it with an IoC library like ninject

Bind().ToMethod(i => new AutoMapperConfig() { new MappingClass1(), new MappingClass2() } );

public Destination SomeFunction(IAutoMapper mapper) {
var source = new Source();
return mapper.Map(source);a
}

Probably not the best design, but would at least mean I don’t need static objects anymore.

By: NIcholas Blumhardt

NIcholas Blumhardt — Mon, 28 Dec 2009 04:16:39 +0000

An alternative to nested closures (sometimes better, sometimes worse) is the Builder pattern. Build() plays the role of that hokey “Finalize”. Not always appropriate, but another good tool to have in the box.

By: Jarod

Jarod — Wed, 23 Dec 2009 18:36:19 +0000

“With method chaining, you never really know that a configuration operation is finished, unless you put in some hokey “Finalize()” method or something.”

I thought nested closure was ‘cool’, but could not see this benefit.

Nested closure SOLD! Thanks.

By: Gilligan

Gilligan — Wed, 23 Dec 2009 15:30:22 +0000

I always wondered about that Configure() method.