I'm using a legacy database that has some cyclic references. When I consume my Ria service from a SL4 client. (generated entities through my ORM mapper) I get the following error:
There was an error while trying to serialize parameter http://tempuri.org/:GetPublicationPagesResult. The InnerException message was 'Object graph for type 'xxx.Entities.TblPublicationPage' contains cycles and cannot be serialized if reference tracking is disabled.
[Query]
public IQueryable<TblPublicationPage> GetPublicationPages(int publicationId)
{
return this.PublicationLogic.Value.GetPublicationPages(publicationId);
}
I know how to enable it for plain WCF through CyclicReferencesAware attribute or IsRefence=true. But I can't figure out how to do this with WCF Ria Services.
I now understand WCF Ria Services better, I just tried to fix it like I would do it in plain WCF and added a metadataclass to my generated entities:
[DataContract(IsReference = true)]
[DataServiceKey("PublicationPageID")]
[DebuggerDisplay("PublicationPageID: {PublicationPageID}")]
[MetadataType(typeof(TblPublicationPageMetadata))]
public partial class TblPublicationPage
{
internal sealed class TblPublicationPageMetadata
{
[DataMember]
public int PublicationPageID { get; set; }
}
}
Only disadvantages at this point is I have to decorate every property in the metadata class with a [DataMember] attribute...
Use [CyclicReferencesAware(true)]
Related
I have:
[DataContract]
public class A
{
[DataMember]
public int X { get; set; }
}
[DataContract]
[KnownType(typeof(Derived<A>))]
public class Base {}
[DataContract]
public class Derived<T>: Base {
[DataMember]
public T Data {get; set; }
}
Service method returns IEnumerable of Base class containing object of Derived class.
Auto-generated WCF client retrieves data and correctly detects type and creates instances of the Derived class, but Derived.Data.X is not mapped, i.e. has 0. The soap message received is correct.
Any ideas why the generic property of the derived class is not correctly mapped from the soap message in the client?
I strongly recommend you to avoid generics in service contracts. SOA world is not friendly with generic type in the service contract. Please look problems reported by others:
Error when updating service reference.The URI prefix is not recognized
WCF. Service generic methods
WCF generic property is not mapped in derived class
http://social.msdn.microsoft.com/Forums/vstudio/en-US/2a9a2fc6-9e01-4112-8948-4192c516c6e7/how-to-use-generics-in-wcf-service
There is a WCF RIA service exposed via SOAP endpoint. I added this service as a service reference to an another project. When I invoke service's method, i get pleased entity but without nested entites. In other words, there are no [DataMember] attributes on nested members of the entity.
I tried to add [DataMember] attribute on entity's members, but it doesnt work.
Entity:
[MetadataType(typeof(PlnCheckMeta))]
public partial class PlnCheck : IEntityChangeLogable
{
}
public partial class PlnCheckMeta
{
[Composition]
[Display(AutoGenerateField = false)]
public IList<PlnCheck> PlnCheckList { get; set; } // can't get this member
// in service reference
// generated entity
}
Is there any idea how to expose nested members?
Add an [Include] attribute to PlnCheckList
I have a class Car
public class Car
{
private Member _owner;
public string OwnerName
{
get { return _owner.Name; }
}
public Car(Member owner)
{
_owner = owner;
}
}
I'm using it both at Silverlight application and wcf service
So, at application I call WCF service to give me instance of car class, but when I get it at application, I see that _owner is empy.
I know that it is empty because of private, but how can I deal with it?
I'm using this class in my app as model (MVVM) if it could helps :/
For a start none of your properties are marked as DataMembers. The class isn't marked as a DataContract. If this is getting returned from a WCF service I would expect to see:
[Serializable]
[DataContract]
public class Car
{
private Member _owner;
[DataMember]
public string OwnerName
{
//getter
//setter
}
etc..
}
Does Member have to be private? Could it be converted into a property?
Keep in mind that a [DataMember] property needs both a set and a get (so that WCF can read into and from the object).
http://msdn.microsoft.com/en-us/library/ms733127.aspx
From a WCF serialization point of view, your Car class actually looks something like this to the WCF service:
public class Car
{
public string OwnerName { get; set; }
//other public properties here....
}
The WCF serializer uses the .NET class definition as a template for serializing its contents as a simple data transfer object. When the WCF service sends back a Car instance, only the public properties will contain values. The serializer ignores all methods in the class. Also, later versions of WCF don't require the DataContract/DataMember attribute markup.
The _owner variable is never initialized because it is not part of the public properties of the Car class. You'll need to modify the structure of the Car class (maybe add a public Owner property of type Member) to get all the data sent from the WCF service to your client.
When you are using the default Data Contract Serializer with WCF services it serializes and deserializes only the public properties of the class. Also another thing to note is that while deserializing the object graph the constructor is not called. You can have a public property with getter and setter.
Here is a very nice article by Jeremy Likeness explaining the problem similar to yours. From Architecture as well as best practices point of view you can use a POCO class generally called as DTO (Data Transfer Object) when transferring objects between the service layer and the clients.
I have a web service that is currently using asmx. The operations are decorated with WebMethod and each takes in a request and returns a response. I started creating a WCF app and I am referencing the business layer so I can reuse the Web methods. My question is, do I have to decorate each class with DataContract and each property of the request with DataMember?
Currently, one of the classes is decorated with SerializableAttribute, XmlTypeAttribute, and XmlRootAttribute. Do I need to remove these and add DataContract or do I can I add DataContract to it? It is a .NET 2 app by the way. The class also contains a bunch of private fields and public properties, do I need to decorate these with a DataMember attribute. Is this even possible if it is using the .NET 2 framework?
The WCF Service is currently targeting .NET Framework 4.0. A few of the methods need to still use the XmlSerializer, so does this mean I can just decorate the operation with [XmlSerializerFormat]?
Can you elaborate on not using any business objects on the service boundary? and what is DTO?
If possible, can you give an example?
Since .NET 3.5 SP1 the DataContractSerializer does not require the use of attributes (called POCO support). Although this gives you little control over the XML that is produced
However, if you already have an ASMX service you want to port then to maintain the same serialization you really want to use the XmlSerializer. You can wire this in in WCF using the [XmlSerializerFormat] attribute which can be applied at the service contract or individual operation level
Edit: adding section on DTOs
However, putting business objects on service boundaries causes potential issues:
You may be exposing unnecessary data that is purely part of your business rules
You tightly couple your service consumers to your business layers introducing fragility in their code and preventing you from refactoring freely
The idea of Data Transfer Objects (DTOs) is to create classes whose sole role in life is to manage the transition between the XML and object worlds. This also conforms to the Single Responsibility Principle. The DTOs oinly expose the necessary data and act as a buffer between business changes and the wire format. Here is an example
[ServiceContract]
interface ICustomer
{
[OperationContract]
CustomerDTO GetCustomer(int id);
}
class CustomerService : ICustomer
{
ICustomerRepository repo;
public CustomerService (ICustomerRepository repo)
{
this.repo = repo;
}
public CustomerService()
:this(new DBCustomerRepository())
{
}
public CustomerDTO GetCustomer(int id)
{
Customer c = repo.GetCustomer(id);
return new CustomerDTO
{
Id = c.Id,
Name = c.Name,
AvailableBalance = c.Balance + c.CreditLimit,
};
}
}
class Customer
{
public int Id { get; private set; }
public string Name { get; set; }
public int Age { get; set; }
public decimal Balance { get; set; }
public decimal CreditLimit { get; set; }
}
[DataContract(Name="Customer")]
class CustomerDTO
{
[DataMember]
public int Id { get; private set; }
[DataMember]
public string Name { get; set; }
[DataMember]
public decimal AvailableBalance { get; set; }
}
Using DTOs allows you to expose existing business functionality via services without having to make changes to that business functionality for purely technical reasons
The one issue people tend to baulk at with DTOs is the necessity of mapping between them and business objects. However, when you consider the advantages they bring I think it is a small price to pay and it is a price that can be heavily reduced by tools such as AutoMapper
WCF uses the DataContractSerializer which is primarily based upon attributes like: DataContract, DataMember, ServiceContract and so forth. But it also supports SerializableAttribute amongst others. This http://msdn.microsoft.com/en-us/library/ms731923.aspx document gives you all the insight you need.
So it might be that you don't need to refactor all your existing code but it aks some further investigation and testing ;)
I have a WCF service and I'm sharing types with a client in a shared assembly.
If the client create a derived class will it be possible to pass back the derived type to the service so that I can read the added properties through reflection ?
I tried but having issues with KnownTypes since the service don't know how to deserialize the derived type.
[Serializable]
public abstract class Car : ICar
{........
//on the client :
[Serializable]
public class MyCar : Car
{......
when passing myCar to Service I get the exception complaining about knownType but I cant add this on the server since I wont know what the client will be sending through and I want to handle extra properties through reflection.
Possible to register client types as knowntypes at runtime ?
Is this maybe the solution ?
http://blogs.msdn.com/b/sowmy/archive/2006/03/26/561188.aspx
This is not possible. Both service and client has to know what types will be sent in messages. If you want to use known type you have to define that relation to parent type on the service.
Why do you need to know added properties on the server?
I think there is a way.
I vaguely remember that when I studied WCF, I met ExtensionData which should be a mechanism to get everything that does not match the serialization of the class. for example, if you enable ExtensionData and you are in this situation
//Server
public class GenericRQ
{
public string GenericProperty {get;set;}
}
public Service GenericService
{
Public void GenericMethod(GenericRQ RQ)
{
}
}
// client
Public class MoreSpecificRQ : GenericRQ
{
public string SpecificProperty {get;set;}
}
At
Public void GenericMethod(GenericRQ RQ)
{
// the serializer adds automatically in RQ.ExtensionData everything that has come and that does not match the class GenericRQ.
}
On how to enable ExtensionData you to easily search on the web