WCF Serialization

[sureshvijayan]

Hello,

I have to develop a project which uses WCF and Dotnet Desktop application.

I have a Dotnet Class Library (DBClassLib) which functions for database activities and database is placed on remote server.

I need to create a WCF application (DBWCF) which calls the above said class library for database access.

WCF application will be referenced in the Dotnet Desktop Application(DBClient).

I have gone thru some topics on serialization.

Consider in my project, i have to add the details of a Customer such as his id, name, address, zip etc..., and there is a method in DBClassLib project to do this. ClassName : CustomerEntity CE

This class has created like to get fields as properties. CE.name, CE.address, etc...

So from WCF application, i will create object for DBClassLib and set the values like said above.

Now what i am having doubt is data transmission from Desktop and WCF app.

I can create a method in wcf app {getCustName(name,address,...)} which accepts name, address, zip etc as method parameters and set to CE.Name = name, CE.address=address, etc.

Is the above way is fast and perfect or

Create a seperate class (WCFCustomerClass WCC) in WCF application which will have properties like name, address etc and in the desktop application, the user needs to set WCC.name="", WCC.address="",... and pass it as serialization technique.

Which one is perfect in the above...

thankzzzzzzz

[techgnome]

Neither.... make your original class CustomerEntity, serializable and pass that as the parameter....

-tg

[sureshvijayan]

Neither.... make your original class CustomerEntity, serializable and pass that as the parameter....

-tg

The CustomerEntity class is serializable and in Client i tried to create an object of CustomerEntity, but its not working.

[Serializable]
CustomerEntity Class ==> [WCF application] ==> Client Program

what i should do to create an object of Customer entity class in client. I dont want the client to provide dll of CustomerEntity Class. The client should access the WPF application and from there he could create the object of CustomerEntity class.

what i am doing now is briefed in first post.


{a seperate class (WCFCustomerClass WCC) in WCF application which will have properties like name, address etc and in the desktop application, the user needs to set WCC.name="", WCC.address="",... and in "WCFCustomerClass" again i will create an object of "DBClassLib" and set dbclasslibobject.name = wcfcustomerclassobject.name, like that..... so two times i need to work.}

thankzzzzzzzz

[techgnome]

In order to create of object of any kind on the client, the client has to have that object exist on the client.... the dll needs to be on the client, and on the server where the WCF app is located.

-tg

[chris128]

In order to create of object of any kind on the client, the client has to have that object exist on the client.... the dll needs to be on the client, and on the server where the WCF app is located.

-tg

Not strictly true - you dont need to have DLLs present on the client side. You can mark a class with the DataContract attribute on the WCF server side and then your client application can create instances of this class (assuming it has added a Service Reference to your WCF service) and it will be serialized automatically as long as it does not have any properties that use types that are not serializable or Read Only.

Unless I am misunderstanding the question then this would be the best way to go. Make your CustomerEntity class on the WCF server side a DataContract and then your WCF client can just pass an instance of that class in as a parameter to the WCF service call

Here's an example off the top of my head:

Server Side:

<DataContract()> _
Public Class CustomerEntity
      <DataMember()> _
       Public Property CustomerName As String
       'Property implementation here
       End Property
End Class

Client Side (after service reference has been added)

Dim CE As New MyWCFService.CustomerEntity
CE.CustomerName = "John"
'etc etc

Hope that helps

[techgnome]

d'oh! ... Good call... that way if there are any changes, they are kept in synch... I forget about the Datacontract... my last foray into WCF had a bunch of things black boxed by our achitect... so some of the details like that were hidden from us.... :/

-tg

[chris128]

no worries I dont understand why anyone would ban the use of DataContracts but each to their own eh!

Added an example to my previous post to make it clearer for the OP as well.

[techgnome]

it's not that it was banned... it was one of those technical details that I "didn't need to worry about"..... he built it into the baseclass from which all things inherited, thusly black boxing the settings....

-tg

[chris128]

Ohhh right sorry I thought you meant he banned you from using it. I would have thought even if its in the base class then you would at least want your developers to know what it is and how it works but what do I know

[techgnome]

agile programming... we were trying to do a 6 month project in 30 days.... and that was one of those things that's a Ron Popiel setting... "you set it and fuggetit"...

-tg

[mendhak]

None of the above (unless already stated).

Create a class library with your entities in it. Have it referenced in both the desktop app as well as the WCF service. When you reference the WCF service in the desktop app, it will be smart enough to pick up your entities and serialize it to that type. This lets you preserve any logic that you may have added or will add inside your entity classes.

[chris128]

None of the above (unless already stated).

Create a class library with your entities in it. Have it referenced in both the desktop app as well as the WCF service. When you reference the WCF service in the desktop app, it will be smart enough to pick up your entities and serialize it to that type. This lets you preserve any logic that you may have added or will add inside your entity classes.

Whats wrong with using a DataContract as I suggested? Isnt the entire purpose of a data contract to be used in situations like this?

[mendhak]

The DataContract will let you specify what's going back and the shape of what's going back (I want property1, property2, propety7 to be sent across the wire).

But as in any business entity class, the property getters and setters may start introducing logic at some point and that's where DataContracts alone won't help. If you have the same classes on both sides, then you can preserve the logic, but the DataContract can let you specify exactly what goes across the wire - you may not need some properties to go across the wire because they are 'outcomes' of other properties or methods or constructors, etc.

If you don't reference the classes on both sides, you get a 'stripped down' version of the original class and when new logic is introduced, you have to start converting to the new type and duplicating functionality.