Hello, by means of introduction, my name is Alexander Filipov and I am working as a developer for the Telerik OpenAccess team. In my first post I would like to share some thoughts about using Telerik OpenAccess ORM in advanced n-tier web applications. Undoubtedly, the main goal in such architectures is to lose-couple the tiers from each other, so the code is modular and easier to maintain. Here comes the question how Telerik OpenAccess ORM fits into this scenario and which are the layers that it should be used in. The optimal approach is to have not more than two layers that “know” about OpenAccess. One of them is the Data model containing Persistent classes. The other layer is the Business logic that operates on the persistent model and provides data to the upper tiers. This data can be wrapped in additional middle-tier business objects to isolate the OpenAccess specific persistent objects from the rest of the application. These business objects should not depend on the DAL and can be used as transport objects all the way through to the Presentation layer. It is a good practice to use an interface to define the functionality required from the Business logic. This will make relatively easy to replace the BLL and DAL with another data provider (implementing the interface) without changing the upper layers. During the last few weeks we published two demo applications with similar design. I will focus on the simpler one to demonstrate the architecture in action. The workflow is illustrated on the diagram below.
Write operations work the same way except that the presentation layer passes an object to be stored. The other demo project uses a WCF service to distribute data to the Presentation layer. It also has a mechanism for loading dynamically the data provider assemblies. This provides the ability to have many data providers and specify in a configuration file which of them to use. This project is available for download in our Code library as well.