I implemented a generic way to get the object by id from Entities defined in Entity Framework.
But the problem is the object I got has a very weird type like this
{System.Data.Entity.DynamicProxies.MyEntity_C71732021C3A9D6A58BDB6087D29E98CFDE09DA9D53AF0892AFB7918AEF7E61F}
And WCF will fail when serialize this object as the type of MyEntity.
How to make the generic type to be the specific type I want?
It sounds like you're using Entity Framework 4.0 POCO objects. If that's the case, MSDN has a great walk-through on how to get things working:
Walkthrough: Serialize POCO Proxies with WCF
Also take a look at:
Working with POCO Entities (pay close attention to the Serializing POCO Proxies section)
Related
I am using WCF WebAPI to write REST services using WCF.
I am returning my POCO classes as json/xml objects from my service.
Most of my POCO classes contain ICollections as they are part of EF4.1 Code First,
hence I get error :
Cannot serialize member of type ...
System.Collections.Generic.ICollection ... because it is of type -
because it is an interface
To avoid that XMLIgnore and ScriptIgnore is suggested. And there are some problems in custom serialization of JSON in WCF.
Just thought someone might have come across a similar problem and have a better solution or way to configure serialization classes, otherwise I will have to decorate each such attribute with XMLIgnore, etc.
More often than not you probably would use DTOs or (view models in ASP.NET MVC) to decouple from your domain model. And you can use AutoMapper to minimize your code converting between domain models and DTOs.
You have to add [XmlIgnore] and [IgnoreDataMember]. Then the property will be ignored for xml and json response.
Thats right Sandro, [IgnoreDataMember] and [XmlIgnore] is needed.
A little bit more explaination:
[IgnoreDataMember] is needed to exclude the field in json serialization,
[XmlIgnore] is needed to exclude the field in xml serialization.
I found that in WCF WebAPI [ScriptIgnore] or [JsonIgnore] are not working and have no effect, so I'm going back to ASP.NET MVC for json-related REST APIs.
Update[24-Jul-2012] This answer is old, and Microsfot WebAPI has come a long way since, please check before relying on this answer.
I read somewhere in stackoverflow itself that when we use POCO classes for WCF contracts using Poco generator , we need not use DataContract and DataMember attributes.WCF do it auto for you? . I don't know how it manages this.
I created a sample application without using these attributes and I was able to generate those entities on client side and use them. I disabled proxy generation and Lazy loading.
Am i missing anything here.? Is there really no need of putting these attributes.
You did it right way. Since WCF 3.5 SP1 it is not needed to add DataContract and DataMember attributes. If attributes are not used all properties with public getter and setter are serialized.
I'm trying to send objects retrieved by NHibernate over WCF, but whenever a have a property of ICollection I get an exception.
When NHibernate gets the data from the database this property is intitialized with an instance of PersistentGenericSet.
Is there a way I can send a PersistentGenericSet over WCF?
-or-
Is there some way making NHibernate initialize these properties with another type?
The PersistentGenericSet is part of NHibernate (used to track changes in collections). It is based on the ISet interface and classes from Iesi.Collections, which was used to fill a gap in the .Net framework as there isn't a Set type. I guess that WCF has a problem serializing this type.
A quick fix is to change your NHibernate mappings to use a Bag instead of a Set. Then you can use a normal IList<T> instead of Set<T> in your classes w.
A better solution is to create a remote facade which sends DTOs to your WCF endpoints. This will allow you to keep the interface of your internal types separate from those exposed as remote services. Jimmy Bogards Automapper is a great tool which will help with the mapping process.
Edit
After re-reading the problem I had a look around the and came across this article which describes a workaround for sending NHibernate collections over WCF. David Brion has written a good follow up article.
We use custom type to represent Identifiers in our project. It has TypeConvertor attached and it always helped with serialization.
I've tried to use WCF Data Services to expose some data from our system, but faced a problem. Astoria framework do not recognize class as an entity even though I've decorated it with [DataServiceKey("Id")] attribute. If I change type of property to Guid - it totally works :(.
How could teach WCF Data Services to understand this simple class?
After a bit of research and a ton of Reflector work I've found that it's not possible.
WCF Data Services have monumental external metadata support described in detail by Alex James in very good series of posts.
However primitive data types creation is forbidden and key property of the entity should be of a primitive type. Moreover there is no pre- and post- execution hook available to provide run-time conversion from and to string type.
This and limited support of LINQ from NHibernate makes Astoria pretty unusable for me now. Witch is very sad.
As long as the class has a property Id DataServices should serialize it properly. You don't even need the attribute if the property is named ID. Did you see the example I did here. Also, you will find a complete list of OData related articles on http://www.Odataprimer.com. Maybe one of those will help.
Problem:
WCF contract objects cannot implement 2 types of lists (ie: List and List).
Long-winded explanation:
I'm building a WCF service on top of an existing core system, and I'm trying to work out the best way to implement some of my business objects.
The core system utilizes interfaces for all business objects - Person management functionality, for instance, requires that I pass in an object which implements IPerson. Nothing out of the ordinary here.
The goal is to have a contact object (Person) which can be used on the service side of things, and also implements IPerson so that it can be passed into the core without requiring a conversion layer. This all works just fine for items like Person.
The issue comes in for lists: a method in the core, for instance, might require a IPersonList to be passed in, and as anyone who's dealt with inherited generics will know, List does not inherit from IList.
In our currently running ASMX service, we implement this with some up/down casting in the web objects. "WebPerson" will inherit from List, and implement IList explicitly so that the IList properties do not show up on the WSDL.
In WCF, however, if you try to use this same object, you will get the following error:
Type 'Cssi.IBroker.Service.Cssi.Contracts.PersonList' with CollectionDataContractAttribute attribute is an invalid collection type since it has multiple definitions of interface 'IList`1'.
Apparently, now that the new WCF serializer knows how to serialize IList, it's no longer able to ignore the second explicit implementation.
If possible, I'd like to avoid creating a PersonList object just for the contracts and then converting to and from an IPersonList object for each call. Changing the core business logic to use concrete objects designed just for the WCF services isn't an option.
Help!
I ended up deciding the best route was a set of dedicated objects used only for the contracts. With them being dedicated to one task, I was able to keep them cleaner without having to compromise my internal design for the sake of the WSDL. For the WSDL objects themselves, I ended up using arrays instead of IList.
The extra step of conversion is a bit cumbersome, but less than trying to keep my core objects WCF friendly would be.