问题
I need to path information from BL layer to the presentation layer via WCF services .
I thought to do it via DataSets but I saw that people tell that it's a bad practice and it's recommended to use dataclasses.
Can someone explain the difference and the advantages .
Thanks for help.
回答1:
DataSet is an old-school, outdated like-an-OR/M solution which worked fine for a long time in drag&drop developments.
Once you want to expose some logic over a service using WCF or any other framework, you need to take in account that these should transport no useless data and just what client needs to consume, and a client could be an user interface or just another service or backend engine.
In services like WCF the best approach is DTO (data-transfer objects, also known as value objects), which are a light-weight versions of business objects, absolutely unlinked from any layer (it doesn't depend on business, UI, data...) which can be easly serialized into XML or JSON and deserialized in any platform, not only in strongly-typed environments, but also interpreted, dinamically-typed ones, like JavaScript, PHP, Python or Ruby (or many others).
Think about DTO as a class which has the exact number of properties that some consumer needs to work with your service layer.
Practical example: You've a Person class having a Name, SecondName and Age. In your user interface, you need to query some service for a list of Person and there you need to show SecondName only. In this case, you're going to design a class having a single property SecondName and you'll avoid giving a full Person to the user interface through your service layer, because it's cheaper and, obviously, optimal.
If this service layer returns PersonDto objects, a JSON-serialized list of 3 persons would be [{ "SecondName": "Blah" }, { "SecondName": "Bleh" }, { "SecondName": "Blih" }]
. I don't think a DataSet would be that lighty serialization.
Check these articles about DTO:
- http://en.wikipedia.org/wiki/Data_transfer_object
- http://msdn.microsoft.com/en-us/library/ff649585.aspx
回答2:
I blogged about this here
回答3:
Try that - a WCF service should be platform independant, and a DataSet is not. You do not transfer defined documents with DataSets but the internal representation of a .NET specific object.
Try that - a DataSet has a lot of crappy functionality that needs representation in the XML form (change information etc.) but that is totally irrelevant in a properly designed API (which a web servie is).
Try that - no project I have known in the last 10 years from any person I do not consider a junior had a DataSet anywhere, WCF or not. Most people with knowledge went over to OR mappers many many years ago.
回答4:
With untyped datasets, you can't really shape the data you are passing to clients, including your presentation layer. For internal apis this is less of an issue, but if you're planning on expanding your api usage, you should consider the benefits if using statically typed models rather that a broad data container. This counts for both inputs and outputs. With a typed model, you can better define the intended shape of your data, its behaviour and with shared contracts you can take advantage of a shared validation model.
来源:https://stackoverflow.com/questions/9015460/datasets-vs-dataclasses-as-return-type-from-wcf-services