I need to serialize an object to pass it as a parameter in a webservice. I followed the recommendations the the article:
DataContractSerializer Error using Entity Framework 4.0 with WCF 4.0
This Object is quit complex because it resembles a hierarchical data structure.
Now I have a problem, because the related objects (one to many objects) are not loading and their value is null.
This is not a problem if I use Dynamic proxies, however dynamic proxy objects do not serialize for use in a webservice.
I have tried to turn on / off lazy loading in the dbContext but it made no difference.
Any one knows how I can work around this problem, perhaps even loading a proxy object and copying it to a 'Real' Object?
Thanks
If it's a relationship that you really must have, your best bet is to load the data using the normal dynamic proxy object and use something like AutoMapper (or a manual conversion) to convert it into whatever you want to send across the service. You can then ensure that what you want to send gets loaded and populated.
Trying to tell EF and WCF to know how to automatically get it right for a complex hierarchical object just isn't worth the effort compared to doing the loading/conversion manually.
Related
I am building an app where my primary model objects can either be fetched from a Core Data store or from an external source (public API via internet - > JSON - > object). I'm new to Core Data so my question is can I just take my model object as it stands now and make its superclass NSManagedObject? I'd guess that I'd need to make sure my model's properties match the names and types of the data model entities for this to happen. I don't want to have to use two different model objects in the app - one when I fetch from the core data store and one when I fetch from the internet API.
Is there anything else I'd need to do to make my already built model objects compatible for use with core data?
Any guidance or advice would be much appreciated.
Regards,
Craig
You can add some business logic to your object (subclass of NSManagedObject) to enable to creation of such an object from data (ie an NSDictionary of values to be used). The crux will be deciding whether you want those objects managed/saved to your local datastore or not.
I highly recommend becoming familiar with NSManagedObjectContext: http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/CoreDataFramework/Classes/NSManagedObjectContext_Class/NSManagedObjectContext.html
What I have done in a couple of products is just deal with core data objects, and initialize them from data that I pull from the web service. That way you only have apples. Another option would be to make a protocol that defines the behavior of the analogous classes. You would be tempted to make one the subclass of the other, but that could get complicated, depending on your persistence requirements.
Please note that my experience in Silverlight/.Net and WCF is about two weeks of googling and deciphering tutorials. I need to attempt and provide feedback to a client on if Silverlight will be a possible solution to their application needing a RIA front end.
The client has a rather large .Net based application with a UI layer built which greatly relies on the creation and manipulation of specific (personal) classes and objects from the backend (which would be the server side).
A summery of what I understand to be the general procedure: one can pass simple objects containing simple data types, or more complex .Net type objects. Basically anything which can be understood by both client and server side, after serializing.
But what is the limitation to the complexity of an object I can pass? Or phrased otherwise, would silverlight and WCF be able to support the passing of a personalized object which may contain references to other classes/objects and variables etc?
Additional Info (in case it can help):
I am not allowed direct access to their backend code but with the information I have been given I can safely say their classes heavily use inheritance and overloading of functions/methods in the classes.
As far as I know there is nothing specific to Silverlight. There are some things to keep in mind though.
WCF serialization doesn´t like circular references.
All types need to specified in the contract. So watch out with inheritance etc.
In general using DTO's (Data Transfer Objects) and not exposing your business objects is the way to go.
The metaphor is one of message passing as opposed to passing objects. DTO's as Maurice said.
You can get pretty complex, but each object needs to have its contract defined.
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.
We're using the DTO pattern to marshal our domain objects from the service layer into our repository, and then down to the database via NHibernate.
I've run into an issue whereby I pull a DTO out of the repository (e.g. CustomerDTO) and then convert it into the domain object (Customer) in my service layer. I then try and save a new object back (e.g. SalesOrder) which contains the same Customer object. This is in turn converted to a SalesOrderDTO (and CustomerDTO) for pushing into the repository.
NHibernate does not like this- it complains that the CustomerDTO is a duplicate record. I'm assuming that this is because it pulled out the first CustomerDTO in the same session and because the returning has been converted back and forth it cannot recognise this as the same object.
Am I stuck here or is there a way around this?
Thanks
James
You can re-attach an object to a session in NHibernate by using Lock - e.g.
_session.Lock(myDetachedObject, NHibernate.LockMode.None);
which may or may not help depending on exactly what is happening here. On a side note, using DTO's with NHibernate is not the most common practice, the fact that NHibernate (mostly) supports persistence ignorance means that typically DTO's aren't as widely used as with some other ORM frameworks.
It's really about how NHibernate session works. So if you within a session pull an instance of your CustomerDTO and then after a while you should get the same CustomerDTO (say by primary key) - you actually will get reference to the very same object like you did in your first retrieval.
So what you do is that you either merge the objects by calling session.Merge or you ask your session for the object by calling session.Get(primaryKey) do your updates and flush the session.
However as suggested by Steve - this is not usually what you do - you really want to get your domain object from the datastore and use DTOs (if neede) for transferring the data to UI, webservice whatever...
As others have noted, implementing Equals and GetHashCode is a step in the right direction. Also look into NHibernate's support for the "attach" OR/M idiom.
You also have the nosetter.camelcase option at your disposal: http://davybrion.com/blog/2009/03/entities-required-properties-and-properties-that-shouldnt-be-modified/
Furthermore, I'd like to encourage you not to be dissuaded by the lack of information out there online. It doesn't mean you're crazy, or doing things wrong. It just means you're working in an edge case. Unfortunately the biggest consumers of libraries like NHibernate are smallish in-house and/or web apps, where there exists the freedom to lean all your persistence needs against a single database. In reality, there are many exceptions to this rule.
For example, I'm currently working on a commercial desktop app where one of my domain objects has its data spread between a SQL CE database and image files on disk. Unfortunately NHibernate can only help me with the SQL CE persistence. I'm forced to use a sort of "Double Mapping" (see Martin Fowler's "Patterns of Enterprise Application Architecture") map my domain model through a repository layer that knows what data goes to NHibernate and what to disk.
It happens. It's a real need. Sometimes an apparent lack in a tool indicates you're taking a bad approach. But sometimes the truth is that you just truly are in an edge case, and need to build out some of these patterns for yourself to get it done.
I'm assuming that this is because it
pulled out the first CustomerDTO in
the same session and because the
returning has been converted back and
forth it cannot recognise this as the
same object.
You are right. Hibernate can't. Consider implementing Equals and Hashcode to fix this. I think a re-attach may only work if you haven't loaded the object within this session.
I'm looking to push my domain model into a WCF Service API and wanted to get some thoughts on lazy loading techniques with this type of setup.
Any suggestions when taking this approach?
when I implemented this technique and step into my app, just before the server returns my list it hits the get of each property that is supposed to be lazy loaded ... Thus eager loading. Could you explain this issue or suggest a resolution?
Edit: It appears you can use the XMLIgnore attribute so it doesn’t get looked at during serialization .. still reading up on this though
Don't do lazy loading over a service interface. Define explicit DTO's and consume those as your data contracts in WCF.
You can use NHibernate (or other ORMs) to properly fetch the objects you need to construct the DTOs.
As for any remoting architecture, you'll want to avoid loading a full object graph "down the wire" in an uncontrolled way (unless you have a trivially small number of objects).
The Wikipedia article has the standard techniques pretty much summarised (and in C#. too!). I've used both ghosts and value holders and they work pretty well.
To implement this kind of technique, make sure that you separate concerns strictly. On the server, your service contract implementation classes should be the only bits of the code that work with data contracts. On the client, the service access layer should be the only code that works with the proxies.
Layering like this lets you adjust the way that the service is implemented relatively independently of the UI layers calling the service and the business tier that's being called. It also gives you half a chance of unit testing!
You could try to use something REST based (e.g. ADO.NET Data Services) and wrap it transpariently into your client code.