Use for extensibility and customization of applications

Sep 30, 2013 at 10:31 PM
Edited Sep 30, 2013 at 10:39 PM
I am working on design for extensibility and customizability that can be quite complex. For example

.Product Set
.. 1 to 7 products in the product set
... n number of customer for a particular product that a project team would customize
.... customer may do some customization once deployed.

I am looking at approaches to support this type of requirement and appreciate any thoughts you have on how this could be done. For instance, thinking of what Use Assman says about using certain patterns to support extensibility and variability:

Also looking at Microsoft product desings.
As described in The Anatomy of a LightSwitch Application Part 3 – the Logic Tier (, extensibility is supported with Executing (pre) and Executed (post) methods of query and submit pipelines. And in addition EntitySet_Validate, EntitySet_Inserting (pre), EntitySet_Inserted (post), and other methods in submit pipeline.

Dynamics CRM
And in Microsoft Dynamics CRM extensibility is similarly supported:
• The Extensibility Model of Microsoft Dynamics CRM ( discusses processes (formerly workflows), Plug-ins, Client Application Extension, and Event Framework.
• Event Execution Pipeline ( “Whenever application code or a workflow invokes a Microsoft Dynamics CRM Web service method, a state change in the system occurs that raises an event. The information passed as a parameter to the Web service method is internally packaged up into a OrganizationRequest message and processed by the pipeline.
[…] Plug-ins can be registered to execute before or after the core platform operation. Pre-event registered plug-ins receive the OrganizationRequest message first and can modify the message information before the message is passed to the core operation. After the core platform operation has completed, the message is then known as the OrganizationResponse. The response is passed to the registered post-event plug-ins. Post-event plug-ins have the opportunity to modify the message before a copy of the response is passed to any registered asynchronous plug-ins. Finally, the response is returned to the application or workflow that invoked the original Web service method call.”

Extensibility with pipeline/event/plug-in
So, I am investigating whether could support extensibility requirements with the help of this type of pipeline/event/plug-in approach. Also considering how workflow and rules engine could also help. For example, after a solution has been deployed to a customer, if they want to add a new column to a table, and then corresponding control to display it in the UI, they could:
  1. Add a column to table
  2. Update ORM/DAL/Data Model to handle this new column, adding field/property to Entity that is returned and accepted
  3. Derive a new form from an existing form and add new controls
  4. Implemented logic in handlers for new controls
  5. If need to change the logic in a handler that is already implemented, for instance Form_OnLoad, instead of changing, implement new logic in Form_OnLoading (pre), Form_OnLoaded (post)
  6. Implement version tolerant service layer, with backward and forward compatibility
    a. For instance with WCF’s ability to support backward and forward compatibility preserving unknown elements and forgiving missing elements. Best Practices: Data Contract Versioning ( , Forward-Compatible Data Contracts (
    b. So in the simplest case that no business logic changes, service layer simply passes data through to ORM/DAL/Data Model where the new field can be handled.
  7. For services that return data to the client UI, consider expando objects (JSON) or DataSets for easier extensibility; and to not force application developer to create and modify classes for data displayed in UI, in textboxes, grids, and other controls; for instance, if add a column to a grid, can modify the service that the UI calls to return extra column in an expando or DataSet without having to update a ViewModel class with the extra column.