Share
ReportI'm going to be having a discussion soon with some colleagues about Dependency Inversion Principle, and it being applied to a 365 online plugin project. I'm not an expert on SOLID principles so I'm not on solid ground here (if you pardon the pun). My thoughts are that the plugin execution construct is already abstracted away in 365 online, so I already have a suitable level of dependency inversion because of the pluginExecutionContext. Don't I? I'm unsure and a bit worried that I'm missing the point. Can you help clarify?
As further detail on the situation..... Any external services I might want to interact with are going to be accessed via Azure aware plugins & the ServiceBus. Any dependency controllers I add to the Plugin project, Autofac etc will need to be merged into the dll and pushed up to 365 online - I think it would be bloating the plugin dll for no benefit.
I typically use FakeXrmEasy to give me mocking for unit testing which gives me some opportunity to swap out contexts at the interface level, so I'm not seeing the need for anything extra there.
So - my question to the community is this.... Do I really need to implement the Dependency Inversion Principle on 365 online plugins? If so, why? Please detail the rationale behind your answer. :)
*This post is locked for comments
All responses (
Answers (
291,269
