I was curious to see the mechanism that Orchard uses internally to wire up a concrete class to a content part; the syntax used in data migrations is very loose, and while all the examples clearly show specifying a class name, the specific mechanism of
Part -> Driver relationship was always unclear to me.
After stepping through the code, I now understand that Orchard retrieves a list of ContentPartDrivers and matches parts to drivers based on name, i.e. if I've got a part defined on a content type named FooBarBaz, and a driver of type ContentPartDriver<FooBarBaz>
in my module, that driver will be selected to be constructed and stored in the content items Parts collection for that particular part.
What I was surprised by is the lack of fidelity; from a newcomers perspective, this mechanism of action is
very counter-intuitive. I always expected to see a .WithClass() method on the builder in migrations.
It doesn't appear that resolution of a driver is limited to any sort of scope, nor does it appear that there is anyway to distinguish one driver from another; for example, looking at the implementation I'm assuming Very Bad Things (tm) would happen if someone
were to load two modules in an installation that happened to have drivers with the same name. Is this prevented by virtue of the fact that no two parts can have the same name?
Lastly, has any testing been done to identify the number of drivers at which performance begins to suffer during content item activation?
It's an interesting design, and I'm trying to learn from it. Thanks for the help!