This project is read-only.

Dependency Suppression and Private Properties

Topics: Core, General, Writing modules
May 24, 2014 at 3:24 PM
One of the best things about Orchard is how extensible it is.

For example, If I wanted to change something such as the order that the layers are displayed in the drop down in the widget screen (for example, to make them appear in alphabetical order), then I can simply create a new class that both inherits from and suppresses (using the OrchardSuppressDependencyAttribute) the WidgetsService class, override the GetLayers method and viola- I have altered a core area of Orchard without making any changes to the original code base. Pretty cool.

However, what if I wanted to do something a bit more complex? What if I wanted to change how a method on the ContentPartDriverCoordinator class worked? Well I would go down exactly the same route (inherit, suppress, override). So far, so good.

Now, in the method that I am overriding, I would like to access a list of available IContentPartDrivers. The base class that I inherited from already has this- I know because I had to inject them into my new class and pass them down to the base constructor. The base constructor then put this collection into a private field so that it can use this collection as and when needed.

And that is where the stumbling block is- the base class has put the injected objects into private fields- meaning that my new class cannot access them.

Now the way around this would be to create your own private field to store this injected dependency, and that is what I have done. However, I'd like to open up for discussion the idea of placing injected objects and services into protected fields as opposed to private. This, of course, would mean that classes that inherit from others can utilize the base classes' injected objects instead of requiring the workaround mentioned above.

What are people's thoughts on this change? Can anyone think of any other pros to doing this? What are the cons?
May 26, 2014 at 8:56 AM
Sounds like a great idea to me. I could not think of any cons for this kind of implementation and it does give a great advantage for inheritance.