One of the requirements for my team is to ensure any software we build for our own organisation could be packaged up and sold to another organisation with instructions on how to customize and deploy it. This came about through various requests for our software that had been shown at conferences and demonstrations. Back when the original requests came in (2007-2008) we would have had to do a significant amount of work to be able to “sell” the applications. One of the requests was from a Healthcare software vendor, wanting to purchase an application we wrote to address inadequacies in their system! Most requests however come from other Healthcare organisations (including Government) and they have just seen what we have produced and think it will also work in their environment. This requirement now exists by default for most new applications unless there is a specific reason we would not want to sell a particular application.
I am not sure if this kind of requirement is common in other industries. I am assuming not because in a lot of industries that are developing custom software, each company is trying to get a competitive edge by building software that makes them more efficient and gives them an advantage over their rivals. In the not-for-profit Healthcare space we share as many ideas as possible with other Healthcare organisations and Government Healthcare agencies to help reduce rework and produce a better outcome for patients.
Our team primarily builds web applications. Back in 2007 when this requirement was introduced the best solution seemed to be to use the ASP.NET Provider Model. We successfully used that in applications up until now and it works nicely. Before the introduction of IOC into our team, it gave us nice separation of concerns for our “integration” code. Basically any functionality that was not core to the system would be extracted out into a “custom provider”. So for example, “SearchForPatient” might be a method on one custom provider. If another company were to purchase the software and deploy it, they could create their own implementation of the custom provider (which is just an abstract class) and implement that patient search method to search their own repository of patient data. They could then drop the DLL into the BIN folder and update the web.config to tell the application to use their provider instead of ours. This was a good solution for its time, but can cause issues with nasty configuration as there are no conventions!
With such great IOC containers available (we are currently using AutoFac for ASP.NET MVC applications); I have started to investigate if there is a “better way” to achieve this “saleability” than using the Provider Model. If we use IOC properly, we might be “double hopping” in order to use a provider – because the IOC container needs to register the custom provider, which then uses the provider’s config to set itself up and get an implementation instance. I have not done any performance testing but this seems like overkill and if nothing else it is a bit confusing for new developers. In another project I have seen, there is a mix of IOC and providers due to commonly used providers such as the Membership and Role Providers. So that is a good example where the project will generally have an interface to wrap the Membership Provider methods it needs, then the implementation at run time will pick up a class that instantiates the Membership Provider via configuration (as normal) and passes through the calls to that Membership Provider. It makes sense to do that because the OOB Membership Providers have a lot of logic within them that you don’t want to be replicating. However in my case, we are hand-rolling Custom Providers which would then get wrapped by an interface and calling implementation class for IOC purposes – so it seems wrong.
One option to replace the Provider Model would be to use the configuration "mode" of an IOC container. This could be slightly cleaner than the Provider Model because you could programmatically hook up the dependencies by default, but just allow configuration as an optional “override”, leaving our in-house code base nice and clean but anyone else who uses it with a bit of a configuration mess.
Another option might be MEF. The next version of MEF (still in preview) is a viable IOC container and it has some great conventions which should allow someone to “drop in” an implementation over the top of the default one and that could pick it up with absolutely no configuration!
For now since we have decided to go with AutoFac in MVC project my aim is to set it up that way to do away with any Provider Model implementations in those new MVC projects.
I jumped on the IOC bandwagon later than I would have liked to (and am never looking back) so I would be interested to hear some comments from some IOC/MEF “gurus” on whether I am heading down the right track or if there is something I have not thought of! Also if you are facing a similar issue and want to discuss leave a comment.
Hi Andrew,
ReplyDeleteSorry for commenting on an old post. One thing you might want to do is use your web.config file to configure Autofac. You can register components through there as well as in code (they'll co-exist happily together) and that will allow third parties to provide their own implementations of various interfaces. They don't need to know anything about the IoC container you're using - they just need to link against your core library, implement the interface you care about and then hook it up via web.config.
If people are subbing in their own providers already using the .NET provider model then they'll already be used to doing the XML transformations, so it should be a low-cost change.