Is it advisable to use datacontract directly into Data Access Layer in WSSF.

Topics: General Discussion Forum
Sep 19, 2009 at 1:33 PM

I want to know why do we need to to translate a data conract to Business Entity? why can't we access data contract in Data Access layer directly.

Sep 21, 2009 at 10:24 AM

As you can read here,

"A data contract is a formal agreement between a service and a client that abstractly describes the data to be exchanged. That is, to communicate, the client and the service do not have to share the same types, only the same data contracts."

Take a look at this WS Architecture overview.

Notice figure 2 (Logocal View) and how you can separate the "Data Type" (Data Contracts) with the Business Entity through the "Entity Translator".

Sep 21, 2009 at 10:35 AM

 Hi hernandelahitte

Thanks for the update but,  my real doubt is whether it is necessary to use business entity in the data access Layer, Can't we access the the data contracts directly in data access layer.

The problem with WSSF translator is, although it can translate primitive data types, its not providing translation for data contracts of  collection type.

Thanks in advance.


Sep 21, 2009 at 11:24 AM

Actually you can access the DC in your DAL. The suggested pattern will let you get a "cleaner" decoupling between DC and the inner layers (BL, DAL) so you don;t need to get references to your Service layer in your DAL that may be shared by other services or applications. That's one of the reasons that you will get your Translators in your Service Implementation layer so you will flow to your inner layers only the BEs that will typically be used by your application layers.

Regarding the collection translation scenario, you may need to update the generated translator with some kind of collection traversing to populate each individual BE/DC member.