Design questions - OpenAccess in Distributed Applications (Ref: Northwind WCF example )

[Manikanta Kiran]

Hi

I have gone through the OpenAcess 101 & dis-connected API webinars.

I have looked at couple of examples from the knowledge base.  The one that seems promising  , Northwind WCF example :

ARCHITECTURE (ref: http://www.telerik.com/support/kb/orm/general/northwind-wcf-demo.aspx)

WCF Service assemblies:

ServiceContracts - Following the WCF practices there is an assembly which contains the service Contract INorthwindService.  This is the contract that contains the endpoints for the service.  
 
ServiceImplementation - This assembly contains the NorthwindService class which implements the INorthwindService interface.
 
ProviderContracts - The goal here is to loose couple the Service Implementation level from the BLL.  To do this, we have a ProviderContracts assembly which contains a ProviderFactory.  In doing so, using reflection, the BBL is loaded by simply stating the assembly name and class of the BLL provider to load which contains the endpoints which service the Service Implementation. The data provider assembly and class names are specified in the Web.config file of the service. This design allows us to have many data providers that can rely on completely different technologies but managing the same data. Nevertheless, only one provider can be used at the same time.
The  Web.config file:

&lt;-- Telerik Open Access Provider --&gt;&nbsp; <BR>&lt;add
key="NWProviderAssembly" value="NSV.NW.OABLL"/&gt;&nbsp; <BR>&lt;add
key="NWProviderClass" value="NSV.NW.OABLL.OADataProvider"/&gt;&nbsp;

The ProviderContracts assembly also contains a Contract for the BLL to implement.

>>>>>>> So, as per my understanding,  because of this indirection,  there is the flexibility to chose any other data provider (another ORM  or other data access technology) provided it implements  the 'Provider Interface' (e.g. : INWProvider) which is an absolute requirement in the architecture for us. 
 
DataContracts - In keeping the layers separated and also to have our own objects to pass through the service, we have a DataContract assembly. The data contracts contain the same fields as the database. There are different ways to do this but here we have assemblers that convert the DB objects to the data contracts. These assemblers take place in the BBL assembly as it is the highest level that manages the database objects. 

>>>>>>> What are the suggested approaches for generating the data contracts. Is there an automated way  as it might be a big overhead to manually create these classes?
 
Other questions :

1. Could please clarify the purpose of the message contracts ?
2. I got a little confused about the dis-connected API. If the proposed architecture (Northwind WCF Example) can work in a distributed environment, what is the need for the dis-connected API which seems to have the OpenAccess code in all the tiers (using ObjectContainers , ObjectScope, ChangeSets etc) ?

 

 

Thanks a lot.

Kiran

[Alexander]

Hi Manikanta Kiran,

I will try to answer your questions in the order you asked them:

1. ProviderContracts - In the Web.config file you can set the data provider assembly name which will be loaded. You can have many providers in the solution implementing the INWProvider but only the one specified in the configuration will be used.

2. DataContracts - I do not think this could be automated. You can use the persistent classes and modify them but this would not be an easy step as well.

3. MessageContracts - they are not mandatory but are used to provide complete control over the structure of the SOAP messages which transmit the data from / to the service. More on the topic can be found here in MSDN.

4. Disconnected API - As you may have noticed, there are a lot of steps to do and code to write in order to produce a strongly layer-separated application as our WCF demo. The Disconnected API provides the option to rapidly produce a client-service application without using proxy objects. However, in this case, using OpenAccess ORM on the client side is required as well as on the server.

I hope this sheds some light on the topic.

All the best,
Alexander
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.

[Manikanta Kiran]

Alexander,

Thanks a lot for  clarifying my doubts.

Thanks for your time
Kiran

[Manikanta Kiran]

Hi

I had one more question :

Is there any overhead in using the provider factory (loading the assembly and creating the class) for every database operation in the proposed architecture ?

Thanks
Kiran

[Alexander]

Hi Manikanta Kiran,

Yes, you are right, creating the provider when initializing the service would speed up the application. However, the method used in the demo allows changing the provider dynamically without restarting the application. If you do not need this feature, you can go with the one-time initialization approach.

Regards,
Alexander
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.