Back to previous page

Typescript Design Patterns for SharePoint Framework Part 2 – Abstract Factory

In my previous post we talked about the factory method design pattern, on this post we will go deeper and explain the Abstract Factory which is in the same family of Creational Design Patterns.

Creational Design Patterns Series:

  1. Factory method
  2. Abstract Factory (this post)
  3. Builder (soon)
  4. Prototype (soon)
  5. Singleton (soon)

Abstract Factory

The abstract factory pattern will allow to define an interface for the creation of objects without specifying their concrete classes. The objective of this pattern is that a class depends on the behavior of the abstract factory, which in turn will be implemented by different concrete classes that are changed at runtime based on some kind of configuration or predefined parameter.

A very good real life scenario where this pattern can be used is in Data Application Layers scenario, more than often developers and architects are faced with requirements where an application needs to be able to access different databases or event different database servers which have different drivers, but the users want to to that without changing a lot of code, something that can be switched from an easy parameter somewhere.

For the sake of simplicity lets suppose you work at Company A, and company A acquired company B, at company A you have a webpart developed that brings Customer Information from Sharepoint List, but at Company B which was acquired and in the process of merging, they have Product Information in their own CRM which exposes data via REST APIs or just a JSON file.

The users wants to see their products in the same Sharepoint page using the same webpart, meaning that the webpart needs to be added twice with different parameters to the same page and users can search for customers information on both data sources, with the same source code.

Project Structure

Abstract Factory

As seen above we have a Factory component and in there we have all files that our project needs, lets discuss them one by one.

Customer.ts

Our model or data access object, nothing to fancy, the idea is to show the pattern, not complex Data Transfer Objects.

DatasourcesEnum.ts

Yay!, we have Enums on typescript, and this will allows to ease work with selections on dropdowns, checkboxlists, etc. In this case is just a dropdown list with 2 options, but I guess you see the benefit here.

DaoFactory.ts

This is the abstract class DAO Factory that would need to be implemented, for the ease of sake, I am doing only one DAO, Customers, but you can use the same pattern for many different DTOs as well on the same class.

JsoDAOFactory.ts

This class is just the implementation of the factory method

SharepointListDAOFactory.ts

This class is just the implementation of the factory method

ICustomerDao.ts

Now, this is the customer interface which defines the methods that would need to be implemented and that depends on the data source endpoint, database or driver, or whatever.

JsonCustomerDAO.ts

Implementation on these methods are left to the reader, but the main idea here is to implement based on the datasource the Data Access Logic here and return the strongly typed objects where needed.

SharepointCustomerDAO.ts

Implementation on these methods are left to the reader, but the main idea here is to implement based on the datasource the Data Access Logic here and return the strongly typed objects where needed.

The component

This is where we actually see the entire benefit of the abstract factory pattern, as you can see the code is really short here and easy to read, no custom business logic, and everything so easy to maintain.

We create a private property of type ICustomerDao to be instantiated on the setDaos method based on the input of the user in the property pane. This method is only called in the constructor once.

And then in the render method we just get the Customer items from the datasource, and as you can see, its totally generic, no custom logic based on the datasource selected.

And just for your understanding, I show below the props and states clases

ITypescriptDesignPatterns02AbstractFactoryProps.ts

ITypescriptDesignPatterns02AbstractFactoryState.ts

And finally the webpart code

TypescriptDesignPatterns02AbstractFactoryWebPart.ts

Conclusion:

We all know that Sharepoint Framework Projects are transpiled and bundled into one single JS file, however regardless of that for those of us who have worked in huge projects and are only User Interface Developers, we know that we can do better than what the standard samples show us in the standard documentation, with the above post I wanted to show you how simple is to create maintenable code, code that anyone can read, and later modify.

About the Author:

Luis Valencia, CTO at Software Estrategico, Medellin, Colombia, independent blogger and still a coder, after 17 years of experience in the field and regardless of my position, and mostly with SharePoint/Office Products, I still love to code, open Visual Studio and bring solutions to users and to the community its what makes me wake up every morning.

Feel free to contact me via twitter direct messages, @levalencia

Reference: 

Valencia, L (2018). Typescript Design Patterns for SharePoint Framework Part 2 – Abstract Factory. Available at: http://www.luisevalencia.com/2018/01/30/typescript-design-patterns-for-sharepoint-framework-part-2-abstract-factory/ [Accessed 12 November 2018]

Share this on...

Leave a Reply

Back to previous page