I'm trying to use nHibernate, Spring and WCF together. I've got an Order object, and that contains a Customer object.
I can call a WCF method findOrder on my service, and providing the Order's Customer field does not have a DataMember annotation, the Web Service returns the Order I wanted. It does not contain the Customer details though, as expected.
But when I try to include the Customer as well, the WebService fails, and looking in the WCF trace logs, I can see this error:
System.Runtime.Serialization.SerializationException:
Type 'DecoratorAopProxy_95d4cb390f7a48b28eb6d7404306a23d' with data contract name
'DecoratorAopProxy_95d4cb390f7a48b28eb6d7404306a23d:http://schemas.datacontract.org/2004/07/'
is not expected. Consider using a DataContractResolver or add any types not known statically to
the list of known types - for example, by using the KnownTypeAttribute attribute or by adding them to the
list of known types passed to DataContractSerializer
Pretty sure this is because the Customer contains extra nHibernate details, but I don't understand why WCF would be happy to send the Order, but not the Customer.
Can anyone help me understand?
Order object
[DataContract]
[KnownType(typeof(Customer))]
public class Order
{
// Standard properties
[DataMember]
public virtual int Id { get; set; }
public virtual Enums.OrderStatus Status { get; set; }
[DataMember]
[StringLength(20, ErrorMessage = "Order name must not be more than 20 characters long")]
public virtual string Name { get; set; }
[DataMember]
public virtual Customer Customer { get; set; }
[DataContract]
...
}
Customer object
public class Customer
{
public virtual int CustomerId { get; set; }
[DataMember]
private string name = "";
...
}
You should use a data transfer objects (DTO) to get your data over the wire. This is good practice anyway as you do not want to let your domain model leak into (and out of) the boundaries of your application.
Think about things like every change in your domain model results in a change of your data contract, resulting in a new wsdl, resulting in a change on the client. In addition you are telling the consumer of your service too many insights of your aplication.
Despite all this architectural bla bla. NHibernate uses proxies to enable lazy loading, those proxies are of another type than you serializer expects. You can disable lazy loading for your domain to get the application working. This is imho a bad idea.
<class name="Customer" table="tzCustomer" lazy="false" >
Related
One of my WCF endpoints has this method:
GetData(DataTable dt)
I tried to create a class on the client that inherits from the DataTable class
public class ExtendedDataTable : DataTable{
//...implementation
}
and pass it along with the endpoint call:
GetData(new ExtendedDataTable());
Then I got the SerializationException. Accordingly to the error, it suggests that I use either DataContractResolver or the KnownType attribute.
I don't want to use the KnownType, because I shouldn't have to update the endpoint every time someone decides to inherit my DataContract. I can't write any DataContractResolver, because I didn't extend the exact structure of the DataTable class. Is it possible to to extend a DataContract from the client?
If so, what's the best practice?
Thanks!
I don't recommend using the Datatable, which makes it easy for WCF to have problems with client and server serialization, such as the need to specify a table name. It is best to use a custom data type, we can use the inheritance type with the KnownType attribute.
https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/data-contract-known-types
On my side, I can't use the inherited Datatable, while I could use an arbitrary custom class by using Knowntype attribute.
Please refer to my code segments.
[DataContract]
[KnownType(typeof(Product))]
public class MyData
{
[DataMember]
public ProductBase Product { get; set; }
}
[DataContract]
public class ProductBase
{
[DataMember]
public int ID { get; set; }
}
[DataContract]
public class Product : ProductBase
{
[DataMember]
public string Name { get; set; }
}
You can try to inherit DataTable and explicitly use DataContract attribute to declare it's name as "DataTable".
But I'm not sure about purpose of this replacement. Server side will see only what is related to original data contract. Even when new properties gets serialized, deserializatin will only work for server side properties. Unless some custom deserialization will be provided.
In all scenarios, using DataTable is not good idea at all as Abraham Qian already pointed out.
The sample apps include a Suspension Manager class that stores session state in a Dictionary, but never attempt to store anything except a string in it.
Whenever I store anything else but a string, then trigger the serialization, I get the following error
Type 'System.RuntimeType' with data contract name 'RuntimeType:http://schemas.datacontract.org/2004/07/System' is not expected. Consider using a DataContractResolver or add any types not known statically to the list of known types - for example, by using the KnownTypeAttribute attribute or by adding them to the list of known types passed to DataContractSerializer.
Do I have to do something else to be able to store other types in SessionState?
You will need to do two things:
Firstly, ensure the type you are (de)serializing is decorated with the DataContract attribute from System.Runtime.Serialization and ensure it's members are decorated appropriately. For example in c#:
[DataContract]
public struct Product
{
[DataMember]
public Guid Id { get; set; }
[DataMember]
public DateTime ManufactureDate { get; set; }
[DataMember]
public decimal Cost { get; set; }
}
Secondly you will need to call SessionManager's AddKnownType<T>() (with T being the type you need) before attempting to (de)serialize it.
looking at the SessionManager code it is only string types, guess you will have to 'roll your own'
http://code.msdn.microsoft.com/windowsapps/ApplicationData-sample-fb043eb2/sourcecode?fileId=43552&pathId=6033729
I have two classes as below:
[DataContract]
public class Address
{
[DataMember]
public string Line1
[DataMember]
public string Line2
[DataMember]
public string City
[DataMember]
public string State
[DataMember]
public string Zip
}
[DataContract]
public class Customer
{
public Customer()
{
CustomerAddress = new Address();
}
[DataMember]
public string FirstName
[DataMember]
public string LastName
[DataMember]
public Address CustomerAddress
}
What will happen if i generate proxy of my service that uses Customer class? If i understand the concept correctly then i think the constructor in the Customer class will not be called at the client side and it may give different behavior.
How do i get rid of that constructor in the Customer class and still have the CustomerAddress property of type Address so that it behaves as a dumb DTO object?
What is the general guideline or best practices that people use to avoid this situation?
If you use the default DataContractSerializer to serialize your objects, then, yes, your constructor is not serialized, and any logic you may have in it will not be called by your client when the object is deserialized.
Regarding your question about removing the constructor logic and having the nested Address class be populated, that will be taken care of by the DataContractSerializer. If I have code like this:
Customer c = new Customer() {
FirstName = "David",
LastName = "Hoerster",
CustomerAddress = new Address() {
Line1 = "1 Main Street",
City = "Smallville",
State = "AA",
Zip = "12345"
}
};
and then return that from a service method, that Customer object will be serialized properly along with the Address information. The proxy on the client that's generated will know about Address and will be able to deserialize the stream coming from the service method to properly construct your Customer object. Your Customer will be a dummy DTO -- no logic, just properties.
Check out Aaron Skonnard's MSDN article on WCF Serialization where he talks about the DataContractSerializer.
If you generate the client (using svcutil or "add service reference"), then the generated DataContract will look like:
[DataContract]
public class Customer
{
// empty default constructor
public Customer()
{
}
[DataMember]
public string FirstName
[DataMember]
public string LastName
[DataMember]
public Address CustomerAddress
}
Your implementation details are not carried over. All that is generated is what goes into the WSDL, which is just the [DataMember] properties in this case.
I mention this because your original question asks: "What will happen if i generate proxy".
If this is an object being sent from the server to the client, then you can just always initialize CustomerAddress before sending it to the client. Infact, if your original code is on the server, then that constructor will be run, and WCF will serialize the CustomerAddress and basically never send a null (unless you set it back to null after the constructor).
If you want to make it so that the client always sends you a CustomerAddress, then you could:
have the server check for null, like if(x.CustomerAddress == null) x.CustomerAddress = new Address();
mark the DataMember as required, then the server will return an error if the client did not pass anything: [DataMember(IsRequired=true)] public Address CustomerAddress;
Otherwise, I don't think there is any way to force the generated WCF client to initialize that field for you.
You'd better define all the data contract classes in a assembly and have both server project and client project reference to the assembly so the initialization behaviour can be shared. When generating service reference, you can instruct the code generator to use existing data contract classes.
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 ;)
Can I have a data contract of this shape??
[DataContract]
public class YearlyStatistic{
[DataMember]
public string Year{get;set;}
[DataMember]
public string StatisticName {get;set;}
[DataMember]
public List<MonthlyStatistic> MonthlyStats {get;set}
};
I am assuming here that class MonthlyStatistic will also need to be a DataContract. Can you do this in a web service?
To use the same model for web services, mark your class as Serializable use the XmlRoot and XmlElement in the System.Xml.Serialization namespace. Here is a sample using your example:
[Serializable]
[XmlRoot("YearlyStatistic")]
public class YearlyStatistic
{
[XmlElement("Year")]
public string Year { get; set; }
[XmlElement("StatisticName")]
public string StatisticName { get; set; }
[XmlElement("MonthlyStats")]
public List<MonthlyStatistic> MonthlyStats { get; set; }
}
You will have to do the same thing for your complex object properties of the parent object.
Yep, thats standard WCF serialization right there. Are you trying to say the MonthlyStats collection has a property called WeeklyStats, or that each individual MonthlyStatistic has a WeeklyStat collection? If its the former, that doesnt work in WCF natively. You will have to do some fiddling in order to get it to work. If its the latter, its perfectly fine.
Yes, you can send the data contract you mentioned above back and forth from a WCF service. Like you said, MonthlyStatistic and all its members will have to be defined as data contracts themselves or be built in types (like strings).
You can even send and receive more complex types like when you have a base class but want to send or receive an object of a derived class (you would do that using the KnownType attribute). While receiving (de-serialization), from Javascript, there's a trick using which you have to specify the type for WCF. If you are interested, feel free to ask.