-1

This might be very trivial, I was just wondering that how is AutoMapper able to create instances of classes with internal constructors.

So I have a 4 Projects UI BLL ENTITY DAL

BLL Has all mapping information, DAL fetches data from DB and creates a new instance on Entity Class which has internal constructor.

in DAL I do

Mapper.Map<dalObjct, EntityObject> (_db.GetItem())

and it returns object of type EntityObject. This all works but I am wondering how AutoMapper creates instance of EntityObject when it's constructor is marked as internal.

Muds
  • 4,006
  • 5
  • 31
  • 53
  • You can do a lot of amazing things one can do with reflection: http://stackoverflow.com/q/2023193/60188, http://stackoverflow.com/q/814183/60188, http://stackoverflow.com/q/19240971/60188 – Anton Gogolev Oct 09 '15 at 11:32
  • yea am sure its happening with reflection, but why would automapper do that ? isn't that breach of abstraction ? – Muds Oct 09 '15 at 11:34
  • @Muds: you're passing internal type as argument. What behavior do you expect from Automapper? – Dennis Oct 09 '15 at 11:39
  • tbh: I expected exception saying cannot instantiate internal objects that are not in the assembly. – Muds Oct 09 '15 at 11:41
  • @Muds: since this code compiles, `EntityObject` type is visible in DAL assembly. This means, that either this type isn't `internal`, or you've set up `InternalsVisibleTo` attribute. So, what's wrong? – Dennis Oct 09 '15 at 11:44
  • oops, correction - class is public, constructor is internal. – Muds Oct 09 '15 at 11:47

1 Answers1

4

how AutoMapper creates instance of EntityObject when it's constructor
is marked as internal

Automapper uses reflection to retrieve type metadata, so, visibility of constructor isn't a problem.

why would automapper do that ?

Because you've asked it to do that.

isn't that breach of abstraction ?

No, it is not.
Automapper, as well as reflection, are just tools. When you use some tool, you must know how, when, and what to use it for.

Dennis
  • 37,026
  • 10
  • 82
  • 150
  • thinking, how easy is it to get over basic restrictions if we use this tools unknowingly. I agree with you, that responsibility lies with us as to how we use the tools, but then same argument can be used in saying why we have abstraction at all as user must always know what to use and how to use .. I understand that in some cases vital information is not available and hence some flexibility is provided.. but in this case this flexibility seems a little unnecessary as while instantiating a new object a check on availability of constructors can be checked. – Muds Oct 09 '15 at 13:01