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.
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.
I am using Microsoft.AspNet.Identity.UserLoginInfo class in my WCF service.
However, I am getting following error -
Type 'Microsoft.AspNet.Identity.UserLoginInfo' cannot be serialized.
Consider marking it with the DataContractAttribute attribute, and
marking all of its members you want serialized with the
DataMemberAttribute attribute. If the type is a collection, consider
marking it with the CollectionDataContractAttribute. See the
Microsoft .NET Framework documentation for other supported types
As the class is in-build provided in Microsoft.Aspnet.Identity library, and also marked as Sealed, I am not getting much help on extending that to make it accessible within my WCF service.
Any help on this will be much appreciated.
Thanks
As it says... you can't. The "Consider marking it with the DataContractAttribute attribute..." is misleading since you CAN'T do this unless you have the source code. I'm assuming that your just want to send some serialized object with a couple properties back to your client. I'd try to just map the current identity to a serializable object and send it back.
[DataContract]
public class MyUserLoginInfo
{
[DataMember]
public string LoginProvider { get; set; }
[DataMember]
public string ProviderKey { get; set; }
}
The later on...
//Return me to client
var loginInfo = new MyUserLoginInfo { LoginProvider = myIdentity.LoginProvider, ProviderKey = myIdentity.ProviderKey };
I have a question about the [DataContract] attribute.
I have written my code like below: here I am not using [DataContract] attribute for my test class.
class test
{
[Datamember]
public string Strproperty
{
get;
set;
}
[Datamemer]
public string Strproperty2
{
get;
set;
}
}
class checktotal:Iservice
{
public string testmethod(test obj)
{
return obj.Strproperty+Strproperty2;
}
}
For that I am sending data from client I am getting the values correctly.
Here is it necessary to use [DataContract] attribute for that test class?
If I removed [Datamember] for test class property is getting error while sending from client. But I am not getting any errors even if I am not using the [DataContract] attribute.
Please give me a brief explanation with example so that I can understand when to give that attribute and when do not give that attribute.
Thanks,
Satya Pratap.
The DataContractSerializer can deal with classes that do not have the DataContract attribute if they provide a default constructor. See the MSDN documentation for more details.
As of .NET 3.5 Service Pack 1, you can omit (not use) the [DataContract] and [DataMember] attributes. If you do that, then the DataContractSerializer in WCF will behave just like the XML serializer - it will serialize all public properties only.
I prefer to use [DataContract] and [DataMember] explicitly anyway - it gives me the opportunity to specify options (like the data contract's XML namespace, the order of the [DataMember]) and it lets me e.g. also exclude certain properties from serialization.
As soon as you start using [DataMember] on one property, then only those properties decorated with a [DataMember] will be looked at for the WCF serialization.
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 DataContract called RecipientDto defined as:
[DataContract]
public class RecipientDto
{
[DataMember]
public string Name
{
get;
private set;
}
[DataMember]
public string EmailAddress
{
get;
private set;
}
public RecipientDto(string name, string emailAddress)
{
Name = name;
EmailAddress = emailAddress;
//Initialize other property here
}
}
I want to have constructor of RecipientDto being exposed to the client as it involve some basic initialization of other properties (not shown here).
Please guide how can I achieve this.
Thank you!
You cannot achieve that unless you share assembly with your DTOs between client and server. Metadata (WSDL + XSD) can describe only data transferred by DTO. They cannot describe any logic defined in DTO on service side.
What you could do is the create a second source file for the RecipientDto class, that contains a second declaration of the class with the "partial" keyword. Add your constructor to it and include that file in your client project using Visual Studio's "Add Link" functionality available on the "Add existing item" dialog. If you only need that constructor on the client then just define that second source file directly in the client project.