WCF Service Powered By CSLA Objects

WCF Service Powered By CSLA Objects

Old forum URL: forums.lhotka.net/forums/t/4706.aspx


wentwj posted on Thursday, April 17, 2008

We're building a WCF Service that uses CSLA objects behind the scenes to power everything.

I'm fairly new to both WCF and CSLA so I hope I understand the interaction between the two correctly.  Currently what I'm doing is converting the CSLA object into a seperatly defiend Data Contract (similarly to how the example Project Tracker app does).  The WCF service then sends that Data Contract back from the client.

To update an object then, the client sends back a Data Contract, which we then run against the CSLA object and make any appropriate changes, run validation, ect.

The issue is that for performance reasons we are using a per-call instanced WCF service, and we then run into issues creating new object.  We want the client to be able to call a "New" operation which generates all default values, including primary keys, and returns the Data Contract for this object.  However, when they go to "insert" it then, since the service is per-call we don't have the object in memory to use.

So our general problem is:
Client calls Service
Service creates CSLA object A {PK=1, A=null, B=null, ect. }
Service returns Data Contract A {PK=1, A=null, B=null, ect }
Client modifies Data Contract
Client passes Data Contract A back {PK=1, A=foo, B=bar, ect}

Now we need to get this Data Contract back into a CSLA object.

Since our CSLA objects don't allow editing of the primary key fields (as well as a few other generated fields), we need to store this object somewhere between the call, or else develop a mechanism in our business objects to accept primary keys to be loaded.  We need to be able to solve this when the service could be running off multiple machines.  If at all possible we'd like to avoid allowing the primary keys to be set directly on our business objects, so some other solution would be preferable.

Anyone else run into this issue, and if so how'd you resolve it?  Any ideas would be greatly appreciated.

sergeyb replied on Thursday, April 17, 2008

Sounds like you do need to allow the setting of primary key.  You can however still have read-only property for primary key and have a public method that loads the data.  I am thinking of something like

 

 

Public Function GetBO (dataToLoad as ISomeConstract) as BO

 _PK = ISomeContract.PK

End Function

 

Sergey Barskiy

Senior Consultant

office: 678.405.0687 | mobile: 404.388.1899

cid:_2_0648EA840648E85C001BBCB886257279
Microsoft Worldwide Partner of the Year | Custom Development Solutions, Technical Innovation

 

From: wentwj [mailto:cslanet@lhotka.net]
Sent: Thursday, April 17, 2008 12:09 PM
To: Sergey Barskiy
Subject: [CSLA .NET] WCF Service Powered By CSLA Objects

 

We're building a WCF Service that uses CSLA objects behind the scenes to power everything.

I'm fairly new to both WCF and CSLA so I hope I understand the interaction between the two correctly.  Currently what I'm doing is converting the CSLA object into a seperatly defiend Data Contract (similarly to how the example Project Tracker app does).  The WCF service then sends that Data Contract back from the client.

To update an object then, the client sends back a Data Contract, which we then run against the CSLA object and make any appropriate changes, run validation, ect.

The issue is that for performance reasons we are using a per-call instanced WCF service, and we then run into issues creating new object.  We want the client to be able to call a "New" operation which generates all default values, including primary keys, and returns the Data Contract for this object.  However, when they go to "insert" it then, since the service is per-call we don't have the object in memory to use.

So our general problem is:
Client calls Service
Service creates CSLA object A {PK=1, A=null, B=null, ect. }
Service returns Data Contract A {PK=1, A=null, B=null, ect }
Client modifies Data Contract
Client passes Data Contract A back {PK=1, A=foo, B=bar, ect}

Now we need to get this Data Contract back into a CSLA object.

Since our CSLA objects don't allow editing of the primary key fields (as well as a few other generated fields), we need to store this object somewhere between the call, or else develop a mechanism in our business objects to accept primary keys to be loaded.  We need to be able to solve this when the service could be running off multiple machines.  If at all possible we'd like to avoid allowing the primary keys to be set directly on our business objects, so some other solution would be preferable.

Anyone else run into this issue, and if so how'd you resolve it?  Any ideas would be greatly appreciated.


Copyright (c) Marimer LLC