0

I have three projects:

  • WCF Service project (Interface and Implementation)
  • aspx web project (client) that consumes the WCF Service
  • class library project that holds my business objects (shared by both WCF project and client)

I have a method in the WCF Service implementation class file that retrieves a generic list of data from SQL (referencing the project that holds the business objects), serialize the data using System.Web.Script.Serialization.JavaScriptSerializer and returns the result as a string.

The web client takes this string and deserializes it back to the appropriate business object (referencing the project that holds the business objects)

This is an intranet app and I want to make sure I am doing this correctly.

My questions are:

  • Should I be using DataContracts instead of business objects? Not sure when to use DataContracts and when to use the business objects.
  • If I am using DataContracts, should I not use System.Web.Script.Serialization.JavaScriptSerializer?

Any clarification would be appreciated.

alpha
  • 501
  • 2
  • 7
  • 22

1 Answers1

0

Of course there is no one answer. I think the question is whether you want to use business objects in the first place, otherwise my fourth point pretty much covers it.

Do use the business objects if they look like the data contracts would, i.e. they are a bunch of public properties and do not contain collections of children/ grandchildren etc.

Don't use the business objects if they contain a bunch of data you don't need. For example populating a grid with hundreds of entities begs for a data contract specific to that grid.

Do use the business objects if they contain validation logic etc that you would otherwise have to duplicate in your web service.

Do use the business objects if you are just going to use the data contracts to fully inflate business objects anyway.

Don't use the business objects if you ever want to consume that service interface from non .net code.

Don't use the business objects if you have to massively configure their serialization.

Don't use the business objects if they need to "know" where they are (web server or app server)

Not your case but: Do use the business objects if you are building a rich client for data entry.

Thats all for now, I'll see if anything more occurs to me. :)

PatFromCanada
  • 2,738
  • 1
  • 27
  • 27
  • Thanks for the response. Some questions to your response: – alpha Apr 01 '13 at 18:45
  • "Don't use the business objects if you have to massively configure their serialization" -- I am not decorating my class with any type of serialization other than in the service class where I serialize it with System.Web.Script.Serialization.JavaScriptSerializer. What do you mean by "massively configure their serialization". – alpha Apr 01 '13 at 18:55
  • Also, Since the business objects look like datacontracts and they are going to be used to fully inflate business objects, then it looks like I can use business objects in this case. I am not going to use DataContracts. Just wanted to confirm. I've seen sites where they recommend using both business objects and datacontract and using automapper to map the two. – alpha Apr 01 '13 at 18:56
  • An upvote is worth a thousand thanks. :) If I have answered your question then you should mark it as answered. – PatFromCanada Apr 01 '13 at 19:00
  • You would configure the serialization if you did not want parts of the data to be serialized, or if they would not serialize properly otherwise. Circular references can be nasty here. Another example is if you don't want to serialize an object's children. Another is where you start with multiple references to one object and the deserialized graoh has instantiated multiple objects where you want just the one. – PatFromCanada Apr 01 '13 at 19:02