The WordPress.com stats helper monkeys prepared a 2013 annual report for this blog.
Here’s an excerpt:
The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 22,000 times in 2013. If it were a concert at Sydney Opera House, it would take about 8 sold-out performances for that many people to see it.
Click here to see the complete report.
after some months of studies about MEF, Unity and EntityFramework I decided to share some “pre-cooked solution” about what I learned.
The first sample provide the basic knowledge about modularity architecture. You can download the sample application (VS2012) here.
As displayed in the picture you have three main actors:
Program: the Program knows just the Core library and it is totally unaware about Plugins components. This means that your Program does not have references on Plugins.
Core Application: the Core Application defines the Plugin Interface (IPaymentPlugin) and provides the PaymentService, a way for retrieving Plugins implementations. We will discover in an other post about why I choose to define the IPaymentService interface (when I will discuss about Unity).
Plugins: each plugin implements the Plugin Interface (IPaymentPlugin).
The core of the application is implemented by GetPaymentPlugins a method of PaymentService of course. Here the code that is able to dynamically retrieving Plugins:
public IList<IPaymentPlugin> GetPaymentPlugins()
List<IPaymentPlugin> plugins = new List<IPaymentPlugin>();
List<Assembly> allAssemblies = new List<Assembly>();
string path = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
foreach (string dll in Directory.GetFiles(path, "*.dll"))
Assembly assembly = Assembly.LoadFile(dll);
foreach (Type ti in assembly.GetTypes().Where(x => x.GetInterfaces().Contains(typeof(IPaymentPlugin))))