I want to return an anonymous type over WCF. Is this possible?
You cannot use anonymous types, but maybe you are talking about WCF and untyped messages?
There is an option in WCF to just define a parameter of type Message (and possibly a return value of the same type). This is just the raw message that goes to WCF (and comes back from it).
I can't find much good information out there - there's some documentation on MSDN, but the best I've seen so far is Kurt Claeys' blog post WCF : Untyped messages on WCF operations.
I would not recommend using this approach - it's a lot more grunt work to handle the message contents directly yourself and that's what WCF is trying to spare us from - but if you absolutely, positively have to tweak every bit of your message - this seems like the way to go.
Marc
You can't return an anonymous type from any method, can you? So why would you be able to return it from WCF?
Looks like you cannot do so with the XML Serializer because of some complaint about a parameterless constructor but it works for the json serializer if you are serving to an ajax client as indicated by Dave Ward.
OK, I understand. But then if I define
a type - MyObj - for this purpose and
mark its members IsRequired=false, how
can I create+send across an instance
of MyObj with only some of its
members? Is this possible??
Take a look at [DataMember(EmitDefaultValue=false)]
No, it is not. You'll have to define your types ahead of time.
You definitely can return anonymous types. This works, for example:
public object GetLatestPost()
{
XDocument feedXML = XDocument.Load("http://feeds.encosia.com/Encosia");
var posts = from feed in feedXML.Descendants("item")
select new
{
Title = feed.Element("title").Value,
Link = feed.Element("link").Value,
Description = feed.Element("description").Value
};
return posts.First();
}
If you call that method as an ASMX ScriptService's WebMethod, you'll get this JSON from it:
{"d":
{"Title":"Using an iPhone with the Visual Studio development server",
"Link":"http://feeds.encosia.com/~r/Encosia/~3/vQoxmC6lOYk/",
"Description":" Developing iPhone-optimized portions of an ASP.NET ..."}}
You can use a return type of IEnumerable to return a collection of anonymous types also.
You can use the ExpandoObject. When you define a property in a DTO as ExpandoObject the client is generated as Dictionary:
Contract DTO
public class TaskDTO
{
public string Type { get; set; }
public ExpandoObject Args { get; set; }
public string Id { get; set; }
public TaskDTO SuccessTask { get; set; }
public TaskDTO FailTask { get; set; }
public bool IsFinal { get; set; }
}
Client
using (var client = new JobServiceClient())
{
var task = new TaskDTO
{
Id = Guid.NewGuid().ToString(),
Type = "SendEmailTask",
IsFinal = true
};
dynamic args = new ExpandoObject();
args.To = "who#mail.com";
args.Title = "test job service";
args.Content = "test job service";
task.Args = ((IDictionary<string, object>)args).ToDictionary(i => i.Key, i => i.Value);
client.Execute(task);
}
Service
dynamic args = dto.Args;
Related
We're getting ready to create a project where we want to expose data to the public via OData and Soap (to let the users of our API's choose which format they want to consume). I know that the Web API allows you to expose a public action method that has an IQueryable as the return type, and that T value then become queryable from OData. The problem is that our web server sits in a DMZ, and will NOT have direct access to the Entity Framework, thus no direct access to IQueryable. Access to the internal network is done through WCF.
Is there a way to receive the values from an OData call, and proxy those through parameters to the internal network? I've been scouring the internet, and so far, haven't found anything useful. I was thinking I'd just grab the query string directly, pass that through to the internal network, and there, use something like PredicateBuilder to create an EF expression tree, and return the data. That would work, but I'm wondering if there's a better way.
Thanks in advance!
It's very easy to handle the OData queries yourself and you can return IEnumerable, IList, PageResults or whatever. Here's an example:
[HttpGet]
[ActionName("Example")]
public IEnumerable<Poco> GetExample(ODataQueryOptions<Poco> queryOptions)
{
//simulate an EF DbSet for the example
var data = new Poco[] {
new Poco() { id = 1, name = "one", type = "a" },
new Poco() { id = 2, name = "two", type = "b" },
new Poco() { id = 3, name = "three", type = "c" }
};
var t = new ODataValidationSettings() { MaxTop = 2 };
queryOptions.Validate(t);
var s = new ODataQuerySettings() { PageSize = 1 };
var results = queryOptions
.ApplyTo(data.AsQueryable(), s) as IEnumerable<Poco>;
return results;
}
public class Poco
{
public int id { get; set; }
public string name { get; set; }
public string type { get; set; }
}
I’d suggest creating a WCF Data Service using your Entity Framework model and make that service available to the DMZ server. I’ve been running a web site, on a DMZ server, with this configuration for a few years now and it has worked well. However, I will admit that WCF Data Services does have some limitations (compared to direct access to Entity Framework) on how you can compose your IQueryable queries but seems to improve with each release.
I have the following class I'd like to send from my WCF (C#) service to my client (WPF):
[DataContract]
public class OutputAvailableEventArgs
{
[DataMember]
public int ID { get; set; }
[DataMember]
public string Message { get; private set; }
[DataMember]
public bool IsError { get; private set; }
public OutputAvailableEventArgs(int id) : this(id, false, "") { }
public OutputAvailableEventArgs(int id, string output) : this(id, false, output) { }
public OutputAvailableEventArgs(int id, bool isError, string output)
{
ID = id;
IsError = isError;
Message = output;
}
}
It's used by the service as follows:
var channel = OperationContext.Current.GetCallbackChannel<IClientCallback>();
channel.OutputAvailable(new OutputAvailableEventArgs(1, false, "some message"));
At the client side, the members get their default values.
I tried marking them with IsRequired attribute but now the OutputAvailable at the client is not called. The code at the service side seems to run smoothly (I didn't notice anything with the debugger).
How can I transfer a DataContract class with WCF while maintaining the members' values?
(I saw solutions that suggested to use OnSerialized and OnDeserialized but I don't need just a default constructor.)
I saw many different solutions for this problem. For other people's sake I'll write some of them down + what worked for me:
It seems that in some cases specifying the items' order solves the problem. Please see this SO question for full details.
If it's some default initialization you're after, you can use OnSerialized and OnDeserialized methods to call your initialization methods.
I also tried using the IsRequired attribute on my DataMembers but still didn't get my objects.
What worked for me was adding NameSpace property in the DataContract attribute. Apparently, In order to have the contracts be considered equal, you must set the Namespace property on the DataContract to the same value on both sides.
The parameter request is always null using Web API. Am I missing something with using a strongly typed object as a parameter instead of simple types as the parameters.
Url
http://localhost:2222/api/v1/divisions?EventId=30
Controller Action
public virtual ApiDivisionsResponse Get(ApiDivisionsRequest request)
{
return _apiDivisionsService.GetDivisions(request);
}
Object
public class ApiDivisionsRequest : ApiAuthorizedRequest
{
public ApiDivisionsRequest()
{
Page = 1;
PageSize = 10;
}
public int EventId { get; set; }
public int PageSize { get; set; }
public int Page { get; set; }
public string[] Includes { get; set; }
}
I very strongly invite you to read the following article to better understand how parameter binding works in the Web API. After reading it you will understand that by default the Web API binds query string parameters to primitive types and request body content to complex types.
So if you need to bind query string parameters to complex types you will need to override this default behavior by decorating your parameter with the [FromUri] parameter:
public virtual ApiDivisionsResponse Get([FromUri] ApiDivisionsRequest request)
{
...
}
And yeah, I agree with you - that's a hell of a mess - model binding was so easy in plain ASP.NET MVC and they created a nightmare in the Web API. But once you know how it works you will avoid the gotchas.
This is one of the classes in Interface file.
[DataContract]
public class ClassX
{
public ClassX()
{
ClassXParameters = new List<ClassXParameter>();
}
public void Add(string name, string value)
{
ClassXParameters.Add(new ClassXParameter() { Name = name, Value = value });
}
[DataMember]
public List<ClassXParameter> ClassXParameters { get; set; }
}
[DataContract]
public class ClassXParameter
{
[DataMember]
public string Name { get; set; }
[DataMember]
public string Value { get; set; }
}
on the client I'm trying to do something like this
ClassX classx = new ClassX();
classx.Add("testname", "testvalue");
But this .Add method is not even visible.
currently I'm doing
ClassX classx = new ClassX();
List<ClassXParameter> params = new List<ClassXParameter()>;
params.add(new ClassXParameter() {Name="testname", Value="testvalue"});
classx.ClassXParameters = params;
Is there anyway I can do what I'm trying to do?
Note: I am not sure why some of the text above are in bold.
If you autogenerate the client code from scratch, it will generate a new class, which contains those members and properties that are marked with DataContract.
If you have methods that you want available on the client, you can accomplish this by putting the DataContract types in an own assembly, which you reference from both the server and the client. When you generate the service reference you have to choose the option to reuse existing classes instead of generating new ones.
Often it is suitable to put data validation rules in the data contract classes property setters. Reusing the data contract assembly in the client will cause the data validation to occur directly on the client, without the need for a roundtrip. It also causes the error in a place where it is much easier to spot than if it is reported as deserialization error.
Data Contracts are for data only. Any methods will not be visible on the client.
The bold was because of the "-----".
I have spent some time writing code for my application assuming that the serialisation bit would be the easiest part of it. Pretty much both sides (client and server) are done and all I need to do is passing a class AccountInfo from the service to the client... The problem is that AccountInfo inherits List and therefore [DataContract] attribute is not valid. I tried using the [CollectionDataContract] attribute but then the class that is received on the other side (client) contains only generic List methods without my custom implemented properties such as GroupTitle...I have worked out a solution for this problem but I don't know how to apply it.
Basically everything works when I make a property instead of inheriting a List but then I can't bind this class to LongListSelector (WP7) because it's not a collection type.
There are three classes I'm on about. AccountInfo that contains multiple instances of: AccountInfoGroup that contains multiple instances of:AccountInfoEntry (this one does not inherit list therefore there are no problems serialising it and all properties are accessible).
Could someone help me using right attributes to serialise and transfer these classes using a WCF method?
Here is the code of 2 of these collection classes:
public class AccountInfo : List<AccountInfoGroup>
{
public AccountInfo()
{
UpdateTime = DateTime.UtcNow;
EntryID = Guid.NewGuid();
}
public bool HasItems
{
get
{
return (Count != 0);
}
private set
{
}
}
public Guid EntryID
{
get;
set;
}
public decimal GetTotalCredit()
{
decimal credit = 0;
foreach (AccountInfoGroup acg in this.Where(item => item.Class == AccountInfoEntry.EntryType.Credit))
{
acg.Where(item => item.ItemClass == AccountInfoEntry.EntryType.Credit).ToList().ForEach(entry =>
{ credit += entry.Remaining; }
);
}
return credit;
}
public bool UsedForCreditComparison = false;
public DateTime UpdateTime { get; private set; }
}
public class AccountInfoGroup : List<AccountInfoEntry>
{
public AccountInfoEntry.EntryType Class
{
get;
private set;
}
public string Title
{
get
{
return AccountInfoEntry.ClassToString(Class);
}
}
public AccountInfoGroup(AccountInfoEntry.EntryType groupClass)
{
this.#Class = groupClass;
}
public bool HasItems
{
get
{
return (Count != 0);
}
private set
{
}
}
}
Thank you for any suggestions... :)
The sample you had is quite painful for WCF in serialization.
What I suggest is you to revised and have a common models for your WCF messages (That means it only contains properties with getter and setter, serialization attributes).
If you have a problem in LongListSelector binding in WP7, you might want to convert the message to the actual type the WP7 object supports to use in binding.