Home → Help and guidance →

IAutomappingConfiguration confusion

MylesRip

17 May, 2010 04:18 PM via web

Admin Functions

• Edit
• Remove

I tried recompiling my project with the latest build (1.0.0.677) and discovered that SubclassStrategy and IsComponentType have been deprecated. Instead, I need to implement IAutomappingConfiguration. When I checked into this interface, I discovered that it includes 14 members that need to be implemented. I further discovered that I apparently need to implement or override this interface in every single class in my domain model. One reason is that I have a Layer Supertype. If I implement this interface in the layer supertype, I would need to have "AbstractClassIsLayerSupertype()" return "true" for this entity. I would then need to override this method in everything that inherits from it to return "false". ( Note: I have several abstract classes within the domain model in addition to the layer supertype. )

Looking at the other members brings up other questions. For example, what should "GetDiscriminatorColumn()" return for tables that don't use a discriminator column? What if I just want to use the default value for the discriminator column name? I have similar questions about the other members of the interface. I checked the wiki, but didn't find any pointers on using this interface. Unless I'm missing something here, it seems that AutoMapping now requires far more configuration making it considerably less "automatic".

Please help. Thanks!

1. Support Staff 2 Posted by James Gregory on 17 May, 2010 04:48 PM

   

   This will all be written up for the 1.1 release. Look at the Example.FirstAutomappingProject to see how to use the automapping configuration. You've got some serious misunderstandings going on.

   How did you discover you need to implement this interface for every single class in your domain model? You need to implement it once, and then pass it to the AutoMap method, that's it. Besides, you don't even need to implement it directly; if you look at the example I mentioned, you'll see there's a DefaultAutomappingConfiguration that already implements all those methods using the default options and you just need to override any method that doesn't work the way you want it to.

   The automapper requires exactly the same amount of configuration it always has done, it's just that configuration has been extracted into an object rather than being built up on the AutoMap method chain. You're still welcome to use it the same way you always have, it's just depreciated.

   As I said, I'll write all this up, but here's a basic example:

   Before

   In your Fluently.Configure call:
   

   AutoMap.AssemblyOf<Person>()
     .Where(type => type.Namespace.EndsWith("Domain"))
     .Setup(cfg =>
     {
       cfg.FindMembers = member => member.IsPublic && member.IsProperty;
       cfg.AbstractClassIsLayerSupertype = type => type == typeof(BaseEntity);
       cfg.IsDiscriminated = type => type == typeof(Product);
     });
   

   After

   In your Fluently.Configure call:
   

   AutoMap.AssemblyOf<Person>(new AppAutoConfiguration());
   

   In another file:
   

   public class AppAutoConfiguration : DefaultAutomappingConfiguration
   {
     public override bool ShouldMap(Member member)
     {
       return member.IsPublic && member.IsProperty;
     }
   
     public override bool AbstractClassIsLayerSupertype(Type type)
     {
        return type == typeof(BaseEntity);
     }
   
     public override bool IsDiscriminated(Type type)
     {
       return type == typeof(Product);
     } 
   }
   

   Admin Functions

   • Edit
   • Remove

2. 3 Posted by MylesRip on 17 May, 2010 05:38 PM

   

   That makes a lot more sense! How I got the wrong idea was this:

   • I downloaded the binaries only, not the source, so I didn't have the example project.
   • I looked at the members in the interface and saw things like "bool IsComponent()" and figured that (in the absence of the example) since it would need to return true for one class and false for another, perhaps it was intended to be implemented by mapping override classes. That was, of course, not a good way to do things, but that's where the confusion came from.
     

   I have now downloaded the source with the example which makes it all clear.
   Sorry to waste your time like that. I'm blaming it on the fact that today's a Monday! :-S

   Admin Functions

   • Edit
   • Split
   • Remove

3. Support Staff 4 Posted by James Gregory on 17 May, 2010 05:44 PM

   

   No worries. I'm sure you won't be alone in this confusion, so at least now I can point people here ;)

   I'll get the wiki updated in time for the 1.1 release, which should be some time this week.

   Admin Functions

   • Edit
   • Remove

4. James Gregory resolved this discussion on 17 May, 2010 05:44 PM.

Comments are currently closed for this discussion. You can start a new one.