Plugin architecture
This section describes the concepts behind ECommerce plugins.
Introduction
ECommerce plugins allow extending the ECommerce functionality and customizing its behaviour. There are two basic design concepts behind ECommerce plugins.
- Seperation of Concerns: Keep your business logic seperate from User Interface logic
- Inversion of Control: Let implementation take the decisions, on matters best known to implementation.
Separation of Concerns
When a project is implemented using Litium Studio, normally you would seperate out the business logic implementation into the code behind files of your website templates, or a set of code files in your app_code directory.
Though this is desirable in most other situations, ECommerce needs a step further. Your custom implementation need to be used by the ECommerce administration as well. For example, you have two ways of placing an order.
- From the public website you create
- From Ecommerce administration, going to orders view and creating the order.
In both above cases, you will be doing order total calculations, and this calculation is depending on your own implementation. Therefore, the logic you provide in that implementation has to be accessible to both administration as well as to the templates you are writing. To do this, you have to place all your logic into the ECommerce plugins where applicable, so that they are available from administration as well.
Below diagram shows, that how both your templates and ECommerce administration use the logic you provide in the plugins.

Inversion of Control:
Some of the detailed customizations you would want to have in your implementation project cannot be generalized.
For example,
- You would have a campaign which is behaving differently from one project implementation to another.
- Different implementations may use different payment providers, delivery providers and pricing rules.
- You would have different order states in different projects, and different state transitions, and different actions that need to be taken in those transitions.
Therefore, implementation project will need the control of telling the Litium Studio API, how a particular functionality should be implemented. This is done using the IOC design pattern. Litium Studio defines the C# interfaces of the plugins that implementation project can provide concrete implementation classes. Then, when the functionality defined by these interfaces are required, these concrete implementations are loaded and used by Litium Studio.
A basic functioning implementation for each of these plugin interfaces are provided with the product, "out of the box". You are free to modify them as you wish, or may also use them without modifications. Plugin source folder in the implementation package contain the full source code of all plugins.
This article describes how you can change the default implementation of an e-commerce plugin.
This article gives a detailed example on customizing a plugin default implementation. The IPriceCalculator plugin implementation is customized usually to take the price from an ERP system. In this example, the price is simply preset to be just 7, with vat percentage at 25%.
The IPluginSelector interface can be implemented to select a particular implementation of a plugin (out of several implementations) based on the business scenario. For example, say there exists two sites one for Business to Consumer (B2C) and another for Business to Business (B2B).
Say for B2C the default implementation of a particular plugin is sufficient, however, for B2B it need to be modified. In this scenario, there exists two concrete implementations of the given plugin, and the implementation to use depends on the business case: whether the website is B2B or B2C.