In the part 1 of this tutorial and the part 2, I explained how the Repository pattern of the LINQ to SharePoint DSL Extension for Visual Studio 2010 is working.
In this new post, I show how to extend the repositories to add your own methods to the business layer. I show also how to use advanced settings as the factory load from a web.config key.
You can implement your own business rules in a repository because all the classes and interfaces generated by the LINQ to SharePoint DSL Extension use the .Net “partial” keyword.
Then, to extend the repository pattern, you only need to write some complementary code to the existing repositories classes. You must implement this code in separate files and write two things:
For example, if you have an entity called Model, and a repository of type IModelRepository, you could add your own methods in this repository thanks to the following code.
First, extend the repository interface:
Secondly, extend the repository LINQ implementation class:
Now you can call this new method in your code:
With this technical, you can easily extend the repository layer with your own business needs. This method helps the developers to use a federated point to code the business methods of the application and reuse it everywhere in the application.
You can notice that, by default, the repository layer factory instances the concrete factory class with the default LINQ to SharePoint implementation. If you want to use a different implementation (for example to test your code is a different data context), you can define the concrete implementation type in web.config (or app.config) key. This method could help you to reduce the level of dependency between your code and the method used to connect to the data.
To use this feature, you must add a new key in your web.config appsettings section, like it:
You can notice that the defined factory class must implement the "IXXFactory" type generated for your model.
To generate a repository layer with this new factory type, you must edit the TT file and set the parameters about it (USE_WEB_CONFIG_FACTORY_TYPE_LOADER, etc.), save it, and run the custom tool again to regenerate the code.
If you do that, the GetNewInstance method of the factory class will use reflection to invoke dynamically the factory instance.
Note: using reflection to construct the factory is slower than the default method. Only use it if you need this feature, and keep the default method if not.