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.
Related
I have taken a step back on two of the approaches in my project (WCF REST Service).
Started with WCFDataServices since it support full OData service stack, but due to more validation requirements on CRUD operations, switched to 'WCF Service' with EF.
And now thinking to step back to use Self-tracking entities to exposing entities to client, as many articles says STE is no more supported by Microsoft and preferred to use OData.(but again WCFDataService not suitable for me).
Please suggest what is the best design here to expose my entities over client.
Alternatively, I may have to write custom classes (Data Contracts) of Entity Model. But, this increases code (for conversion of objects between Custom and Entity) and decreases maintainability.
Please suggest is there any best approach to expose my entities. Your suggestions are valuable and most appreciated.
Fowlers first law of distributed object design states, "don't distribute your objects". This just means give them a copy and not the actual entity itself. If you were to create mirror copies of your entities in your data contract namespace, you retain much more flexibility, should your database schema need changing. If your data contract is initially identical to your entity, a tool such as AutoMapper will eliminate all the conversion code you need to write. Once configured, to convert your entity to your data contract becomes a 1 liner:
Mapper.Map<CustomerDto>(customer);
This takes your customer entity and gives you back a new customer dto. It's all convention based and works by matching up property names. Even if the data contract isn't entirely identical to the entity, you only have to prompt AutoMapper for those properties it can't figure out for itself.
I built a number of WCF services as part of an application. Until recently, most of the classes that were used as parameters of the many operations in a service did not had the DataContract or DataMember attributes applied to them.
Now, I've made a few changes in a row and all of a sudden WCF is complaining that he can't serialize my classes.
Does anyone knows if any changes in configuration or even in the ServiceContract, OperationContract etc. can cause WCF to become picky about the classes it can serialize?
I'd rather not need the attributes in those classes (they should be pure C# classes as possible).
Also of note, if I return to a previous version in my source control, WCF goes back to "normal", so I believe that it's not a machine/environment thing.
The ability to create WCF Data Contracts without the use of the [DataContract] and [DataMember] attributes is a feature added to WCF in .NET 3.5 SP1. Since everything works for you when reverting your code to a previous version, I'm assuming you are already using at least that version.
Nevertheless, in order for classes to be serializable by WCF, the class must meet several requirements listed here. The main requirements of the data contract class are:
It must be public.
It must have a parameterless constructor.
It must not have any data members that do not meet all these requirements. If you do have such a member, mark it with [IgnoreDataMember] and it will be excluded from WCF serialization.
You can get more information about what fails to serialize by performing the serialization manually using the DataContractSerializer class. See this article for more details and code examples. Another method is to mark all members with [IgnoreDataMember] and gradually remove the attributes from members until serialization fails, which will tell you which member is causing the problem.
WCF is lenient towards classes that have [serializable] attribute. You don't require [DataContract]. You must have added something that is not serializable.
I know a way to do that. it's not professional but it works for me
I'm also need pure c# classes so I do it in this way.
I convert each parameter of my class to an object then gather them into array of objects and send it to the other side. in the other side I do the reverse operation to get my parameters back. but this operation will reduce the performance i think
I have been using EF since it first came out. Used to hand build POCOs in 3.5 and was glad to see Self Tracked Entities(STE) in EF4.0.
I have use STEs in a couple of very large projects(500+ entities, some with multiple models). In these projects I use a generic Repository and a generic Unit of Work to persist the entities i.e. 2 small generic classes no mapping. By electing a core entity as the "aggregrate root", other entities are added and updated on the client side and the core entity graph containing these changes is sent to the WCF service and used in the Logic Layer which creates the Repository<[core entity]> and uses the UnitOfWork<[core entity]>.Save(Repository<[core entity]>) to persist the STEs and their children to the database.
Now Microsoft is recommending that we not use STEs. See this article
So my question is, What is(are) the patterns that are now recommended by Microsoft for applications that are persisting client changes to WCF Services that use EF?
I created a EF5 Model and examined the generated code. The there are no attributes for a WCF Service i.e. DataContract, DataMember etc
EF4 had a "ADO.NET DbContext Generator with WCF Support" template, but there isn't a EF5 equivalent.
One site suggested I should use a partial class file and decorate the same properties in that file with these attributes. But unless .net 4.5 has introduced partial properties, I cannot see how that can be done.
Another blog suggested using DTO and Automapper, which means more mapping which is error prone; especially when entity fields change type.
So now that DBContext generated code classes are not Service enabled, does this mean that we need to write another set of classes (POCOs) that:
needs to be mapped FROM the DBContext generated code classes after querying the database.
holds the data state for the WCF Service client(s)
is updatable by that client(s)
is mapped by the client(s)
has the ability to hold changed state so this can be sent back to the WCF Service
needs to be mapped TO the DBContext generated code classes for persistence
It seems we just took a great leap backwards to EF3.
If you code both client and service that runs on your hardware, you don't need to be concerned about data structures at the client as they belong to you.
If you also need to expose some of your service methods to non.NET clients you should do the 5 points above for those services anyway and use DTOs and Automapper in those occasions.These should be in a different WCF Service but implemented against the same Logic Layer, after mapping.
But how many of these type of non.NET client services are be created in the day to day building of web applications in most software teams?
This latest recommendation is confusing as it has not been explained as to WHY STEs are ALWAYS ill-conceived and what now, are the recommended patterns to be used for persisting client changes to WCF Services that use EF.
Can anybody inform me where I can find a good resource that solves this architectural design issue?
P.S.
Please don't recommend WCF Data Services or WCF RIA as we need a lot of control over how your data is retrieved and saved by clients.
Please don't recommend Code First as we use Database First as we want to have and need to control the structure of that database and not have to generated for us.
Ok so i thought the same thing when I first read this article, it seems a bit weird to deprecate a whole branch of EF like this and the intention wasn't terribly well communicated (IMO). I think a couple of things are important here:
STEs as referred to in this article refer to object context based self tracking entities (which act a little like autonomous contexts)
ObjectContext is generally being moved away from in favor of the cleaner DbContext structure (this is for both DB first and Code First)
STEs != DB first generation, you can still use an EDMX model in EF and this isn't likely to change.
When i originally saw this article I mistook STEs for POCO Proxy entities which are still available and AFAIK there are no plans to deprecate. (these achieve a similar technical solution to the problem of change detection but with a nicer interface. Check out this article for the differences EF4: Difference between POCO , Self Tracking Entities , POCO Proxies
So what does this all mean
Basically STEs in terms of the old implementation of a change tracker are being deprecated in favor of the newer forms of change tracking (Snapshot or POCO Proxies). This means that if snapshot tracking doesn't suit you you should look into POCO Proxies which are similar to the old STEs.
You can still use all previous techniques for context generation (DB First, Model First, Code First, and DB-> Code)
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.