Background
In my last engagement in Dynamics CRM, there were different possible integration points involving Dynamics CRM. The business logic had to access different data sources like sharepoint, PostGreSQL , SOAP API.
The integration points had to be developed through a Restful API. The API was consumed from both Dynamics CRM On Premise as well as some 3rd party applications. The article explains how the entire solution was designed and the repository pattern that was used for the same.
Repository Pattern
A repository pattern encapsulates the data layer from business logic by inserting an entity model in between. The business logic just acts on the entity model without considering into the complexities involving the data source behind the data layer. Based upon the integration point, the business logic just queries the entity model which in turn fetches data from the underlying data source. Any updates to the entity model as then transcended to the underlying database
Advantages of Repository Pattern
- Consistent business logic can be applied to the database retrieved from different sources.
- As consistent business logic is applied, code reuse will be more.
- There are several objects from different sources like listitem in sharepoint, Dataadapter objects in SQL and NpgsqlDataAdapter class in PostGreSQL which are weakly typed. They can be mapped to strongly typed classes.
- From the Rest API Client perspective, it only needs to call the exposed method on business logic. Underlying design will implement the logic concerning different data sources without exposing the complexities outside.
Design Architecture
In coming blogs i will go deep down to explain the code structure followed in the repository pattern.
crmazurecomponents 