Why should I use Object instead of DataSet as the return type of my WCF Method? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, refer开发者_Go百科ences, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 11 years ago.

I heard some people saying Returning DataSet as a return type of your WCF method is not a good practice. What are the problems if I use DataSet as return type of my method? What are the advantages of using a List of Objects instead of DataSet?

Sending a List of State object (ID,StateCode,StateName) or DataSet?

I was told by a friend that having DataSet as return type has an advantage. If tomorrow client is saying (assume I published the service and some outside customers are using that), my client is saying I want some more information about the object (ex: Need a "Notes" field about the State), I don't need to change the signature of my contract. I just add the notes to my dataset. This will not break any existing contract.

I heard that there is performance issues if I use dataset? How big is that impact? What are the other issues? Why people write DataSet is evil?

Trying to evolve as a good developer by switching to good coding practices.

---

Dataset leaks platform details. Dataset is microsoft implementation and when you expose that over a service, then clients who use the same platform as the data being exposed can only consume the service. That basically makes your service consumable only on microsoft platforms which against the whole point of a service. Other thing is that dataset when serialized contains huge amoount of unrelated data for a client, like datarelations etc..

And regarding your "Notes" example, Boundaries are supposed to be explicit when you define a service. So the outside world has to know what is the type of data that you are sending across the service and its structure.