I'm putting together a plan for an Xml web service to go into a client's site to be consumed by third-parties so that they can access the client's data.
My question is really asking about best practises here, and at the moment I am deliberating over 2 different strategies:
1) Create an object model which represents my Xml data and serialize it (either explicitly, or implicitly by exposing the data through a Wcf REST endpoint)
2) Transforming my domain model directly into hand-crafted Xml using XLinq and returning this as a string from the service, setting up the response headers appropriately
I like (1) because I let the system do the generation of the physical Xml and I work purely within the object model, but versioning becomes a problem and I might need finer control over the output.
I like (2) because I do get the fine control and versioning becomes easier, but I'm now hand-crafting Xml and the opportunity for error escalates.
Any opinions? Am I missing something which gives me the best of both worlds? I would go straight for (1) if I knew the best way to 'version an object model' - would using different namespaces suffice?
I'd use serialization. As long as you don't try to use your domain objects for serialization you can get pretty fine grained control over the XML either via the DataContractSerializer or the XmlSerializer. You can then map between your domain objects and your serialization objects using something like AutoMapper
Related
I have to read and write data through a protocol where the response XML maybe different according to the error state of the server application. If the response is good it uses let's say Xml_1 with a specific schema but if the response indicates an error it uses Xml_2 with a complete different schema. The good design , in my opinion would be to incorporate the error state to the first schema, but we are just consumers of the this service and we don't have access to the design of the server application. My solution is to (using C#) read the XML response as string, do some searching in order to understand which XML schema is in use and then using the appropriate XML Serializer to convert the response to an object. Is there a more elegant solution?
Is the union of the two schemas a valid schema? (This will typically be the case, for example, if they use different namespaces, but it's likely not to be the case if they are both no-namespace schemas or if they are two versions of the same schema).
If the union is a valid schema, then you could consider validing against that.
Otherwise peeking at the start of the file will often be enough to tell you which vocabulary is in use.
It's possible to parse an XML document without validation, inspect it, and then validate the already parsed document. It's even possible to do this in a single pipeline without putting the whole document in memory. But the details depend on the toolkit you are using. You've tagged the question C# - I'm not sure if this is possible using the Microsoft tools, but it should be possible I think using Saxon-CS. [Disclaimer, my product].
I have the following situation:
User Object
Half of the data for the structure is stored in the DB(owned by me).
Other half of the data is coming from Third Party(via web api).
Another important point is that I want to use ExpressMapper(or any other good suggestions) for mapping Entity/Service objects to DTOs.
I want to use DTO pattern for transferring the user information between different layers.
Questions:
Should I make a large DTO containing all the properties of both of the Service Object and the DB Object?
Should I create Third Party Data Objects as properties of the DTO. I mean hide the Service Data objects behind an interface and make that interface as a property of the DTO.
Do I need to make interfaces for DTO in case 1 or 2?
Generally, the best DTO design has to do with the requirements of the client and the method/function that's returning it. I'm assuming you're doing this for purposes of serializing results.
If you're simply mapping all of the data you're storing to a DTO, you've not really gained much, and could probably just emit the data object you've stored in a serialized way.
So to answer your questions
1) No. You should make a DTO with data that's relevant to the call you're making for a few reasons..
DTO's are generally transferred over the wire in a serialized way. So
smaller = less data.
There can be overhead to populating and serializing a DTO. You don't
want to penalize every call that returns a large DTO with a
burdensome process just to populate a property that isn't relevant to
the purpose of the call.
It might be a bit more self documenting.
Keep in mind that it's okay to send some "irrelevant" bits of data for purposes of code re-use. Just be mindful of how much data that is, and how much effort the process takes to generate the data. No hard and fast rule here more than what makes sense in terms of readability and efficiency.
2) Depends on your application, but I'd be inclined to say that knowing it's 3rd party data isn't usually relevant to the calling client getting the DTO. The 3rd party you're getting your data from could be getting it from 3rd parties as well. But the DTO's they are returning to you are likely not singling that data out for you.
3) Interfaces, again really has to do with the app you're developing. From the client perspective, any interface isn't going to mean much unless you're supplying the library of DTO's in an assembly. If the DTO's are being generated by a proxy (such as adding service reference), or the client is creating their own client-side verions of the DTOs, those interfaces won't carry through to the client.
What are the pros and cons of the following 2 cases:
Case I:
Traditional way:
Add service reference in project. Create object and Get data from service on server side and bind to asp.net grid.
Case II:
Update Service for JSON behavior. Add service reference in project. Call service from javascript to get data. Bind data to jquery grid.
Which one is the best approach and why?(Not developer point of view)
If there is another approach which is more optimized, please explain it and consider for large data.
It depends on whether end-clients (browsers) are allowed to have access to the WCF data service, or just the app service. For simple security modes, having json allows a lot of very simply jQuery etc scenarios.
Of course, jQuery etc demands a compatible browser; these days that means "most", but by no means "all". So if you want to provide the same data to dumb browsers you'll need a way to get the data at the server.
If the intend is to provide server-to-server (B2B etc) access, json is generally a second choice; xml (SOAP etc) would be the de-facto standard, but it isn't the only option. For example, if you have high bandwidth needs you might choose a more compact binary transmission format (there are many).
second approach. any client can now consume that data, whether it'd be jquery grid or even an iphone client.
I have a complex, [Serializable] object stored in session. I have Silverlight 3.0 islands in my .aspx pages that need access to this data and its data type. It is my understanding that Silverlight does not support [Serializable], and since it is running on the client, it does not have easy access to session. I am looking for a solid way to access this data in my Page.xaml.cs file.
I am open to storing it in ISO Storage once it has been retrieved, but how to retrieve, read it from Silverlight? Hidden fields are not an option as it is a complex data type with dozens of properties, and a few dictionaries, lists of other objects.
The classic way of accessing this type of data would be with a silverlight-enabled WCF service on the ASP.NET site that accesses the data. You then add a service-reference from the silverlight client and ask the server for data (asynchronously).
Note that by default this will be a separate object model (proxies from "mex"). If you need the same type you'll have to repeat the code in the client (you can't really use assembly sharing between client and server here).
I don't know whether the silverlight version of svcutil will allow type re-use (the regular version does), but if not another option is to just return xml or binary from the service and deserialize locally. One option here would be something like protobuf-net.
I am working on a webservice where we use LINQ-to-SQL for our database abstraction. When clients use our webservice, the objects are serialized to XML and all is dandy.
Now we wish to develop our own client that uses the native data types since there's no reason to do objects->xml->objects. However, from what I understand you can't transfer LINQ objects as they directly map to the database and as such the data is "live".
My question is whether there is a way to take a "snapshot" of the data you've extracted, set the LINQ object to "offline" and then transfer it. The data will not be changing after it's transferred to our client and we don't need the database access.
The LINQ-to-SQL classes can be used with DataContractSerializer (for WCF) easily enough (you need to enable the serialization property in the designer, though). With this in place, you should be able to share the data assembly with the client. As long as you don't use the data-context, the objects themselves should be well behaved (just disconnected - so no lazy loading).
The trick is that you need to re-use these types (from the existing assembly) in your serialization code. If you are using WCF, you can do this with svcutil /r, or via the IDE.
That said though; it is often cleaner to maintain separate DTO classes for these scenarios. But I'm guilty of doing it the above way on occasion.
If you're willing to use WCF (for the webservice and the client) you can decorate your Linq2SQL generated classes with the [DataContract] and [DataMember] attributes.
Check the following links for some guidance:
http://msdn.microsoft.com/en-us/library/bb546184.aspx
http://msdn.microsoft.com/en-us/library/bb546185.aspx
http://www.codeproject.com/KB/WCF/LinqWcfService.aspx
http://www.aspfree.com/c/a/Windows-Scripting/Designing-WCF-DataContract-Classes-Using-the-LINQ-to-SQL-Designer/