How can I export a C# class (DTO) in the dtos.ts file generated with npm run typescript-ref http://localhost:5000 src/myproject without referencing in the request class?
Note: we have several C# DTO classes (MutationAddressChange, MutationCEOChange...) that we map to the domain class using automapper. So we want to use the C# DTO classes as well in Angular to populate the corresponding type (e.g.MutationAddressChangesCreateDTO) and send it to the web server. Therefore, in the CreateMutationRequest class, we accept an object instead of a specific class.
example DTO-Class:
public class MutationAddressChangesCreateDTO
{
public string Street { get; set; }
public string POBox { get; set; }
public string Zipcode { get; set; }
}
ServiceStack Request-Class
public class CreateMutationRequest : IPost
{
public object Mutation { get; set; }
}
Angular expected use:
{
var mutationAddressChangesCreateDTO= new MutationAddressChangesCreateDTO();
mutationAddressChangesCreateDTO.dateOfMutation = ...
const request = new CreateMutationRequest ({
mutation: mutationAddressChangesCreateDTO,
});
this.client.post(request)
...
}
A limitation of Add ServiceStack Reference feature is that your DTOs cannot have any object or interface properties which creates a black hole in your Services contract that's impossible to generate a Typed API for.
I'd recommend against having any object or interface properties in your DTOs which other than being a source of runtime issues is also limited by security restrictions.
You could use an untyped data structure like a Dictionary<string,string> to store arbitrary values, you can some find other alternatives in this Customer Forums thread.
Although it's discouraged you could still have object properties in your ServiceStack Request DTOs, you just wont be able to generate a typed API for them but you should still be able to send them as an anonymous arg, e.g:
this.client.post(request, { mutation: dto });
Object properties are handled with JS Utils by default which should deserialize it into a Dictionary<string,object> which you should be able to convert back into a C# type using ServiceStack's Reflection Utils, e.g:
public object Any(CreateMutationRequest request)
{
var payload = request.Mutation as Dictionary<string,object>;
var payloadRequest = payload.FromObjectDictionary(typeof(TheType));
}
A similar approach to this that avoids using object is to send a serialized JSON payload in a string property, e.g:
request.mutation = JSON.stringify(payload);
Which you can deserialize using JS Utils again, e.g:
public object Any(CreateMutationRequest request)
{
var payload = JSON.parse(request.Mutation);
var payloadRequest = payload.FromObjectDictionary(typeof(TheType));
}
With that said I don't recommend any of these untyped strategies and would personally create Typed services for each API that's needed which is more intuitive, discoverable & resilient, any shared functionality can easily be handled in your Services implementation using ServiceStack's AutoMapping and .NET's powerful reflection capabilities.
Related
I have a webapi myproj.csproj that is a .net core 3.0 web api. it compiles to a myproj client that contains all the necessary api endpoints and all types explicitly associated with those endpoints.
I have an endpoint that is like the following:
public async Task<string> GetReportDataAsync(Guid reportType, long id)
where I pass in a guid of the report type and another id, it does a calculation and returns a json string. I would like to make the type used to serialize to json on the server side available in my client so I can easily deserialize the string:
string reportOutput = await ApiClient.GetReportDataAsync(<reportTypeGuid>, <id>);
JsonConvert.DeserializeObject<MyReportType>(reportOutput);
without having to create a new API endpoint for every report type I add. Is there a way to force the web api to compile the types I ask it to for easy client consumption?
I could create a new api endpoint for every single report type, but I would rather not do that if I have 10+ report types. The existing endpoint already does what I need it to, I just want to deserialize the type.
I realize it's designed this way to have only what the client would need, just wondering if anyone has run into this.
Report Type (there are more properties than this but they are all of type long):
namespace Reports.ReportTypes
{
public class MyReportType : ReportTypeBase
{
public long JobRunId { get; set; }
public long Size { get; set; }
public long Count { get; set; }
//...
public long SomeOtherCount { get; set; }
}
}
The following documentation illustrates how to use the Options Pattern in ASP.NET Core to create a strongly-typed options class to access JSON configuration data.
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/configuration/options
This C# class
public class MyOptions
{
public string Option1 { get; set; }
public int Option2 { get; set; }
}
represents a portion of this JSON configuration file (the first two root-level properties)
{
"option1": "value1_from_json",
"option2": -1,
"subOptions": {
"subOption1": "subvalue1_from_json",
"subOption2": 200
}
}
I want to add another C# property named SubOptions to the MyOptions class that returns the raw data of the subOptions JSON sub-section, without creating a strongly-typed class for that sub-section of the JSON configuration file, but I don't know what data type to use (or if it's even possible to do that).
If I use string, I get a runtime error when service.Configure<MyOptions>(Configuration); is called, saying System.InvalidOperationException: 'Cannot create instance of type 'System.String' because it is missing a public parameterless constructor.
If I use object or dynamic, I get a different runtime error when service.AddSingleton(cfg => cfg.GetService<IOptions<MyOptions>>().Value); is called to register an instance of the MyOptions class, saying System.ArgumentNullException: 'Value cannot be null. Parameter name: type'
If I use JObject, I get {} back when I access the SubOptions property of the MyOptions object that's injected into my API Controller.
I know I can convert the sub-section to a JSON string property by escaping the sub-section data, but I want to avoid treating the sub-section as a string, and instead leave it as raw JSON.
Is it possible to do what I want to do? Is there a data type that works with the Options Pattern that will allow me to access the JSON sub-section without having to create a strongly-typed class?
*For background, I'm trying to create an API Controller method that returns the content of the JSON sub-section to the API client. I want to avoid using a strongly-typed class for the sub-section, so that the JSON configuration file can be edited on the server, adding new properties and values to the sub-section that will be returned to the API client, without having to update the C# code and redeploy the API service. In other words, I want the JSON sub-section to be 'dynamic', and just pull it and send it to the client. *
You can sorta do get raw configuration object by forcing your SubOptions property to be of IConfigurationSection:
public class MyOptions
{
public string Option1 { get; set; }
public int Option2 { get; set; }
public IConfigurationSection SubOptions { get; set; } // returns the "raw" section now
public string SubOptions_take2 { get; set; }
}
so you would still bind your strongly typed object in your Startup.cs
public void ConfigureServices(IServiceCollection services)
{
services.Configure<MyOptions>(Configuration);
...
}
but this is where luck appears to run out, because even though it is a whole section - as far as options binder is concerned it's all been deserialised and parsed into hierarchy of values already. There appears to be no easy way to reassemble it back into one string. Injecting IOptionsMonitor allows you to get the values by opting for .GetChildren() but I could not find an obvious way to get the whole hierarchy without writing custom code to just recursively walk it (which I will leave out for you to play with should you feel this is worth the effort):
public IndexModel(IOptionsMonitor<MyOptions> options)
{
_options = options.CurrentValue;
var subOptions = _options.SubOptions as ConfigurationSection;
var children = subOptions.GetChildren(); // you see, the config has already been parsed into this hierarchy of items - it's too late to get the raw string value
var s = JsonConvert.SerializeObject(children);
// will produce something like this JSON:
//[{"Path":"SubOptions:subOption1","Key":"subOption1","Value":"subvalue1_from_json"},{"Path":"SubOptions:subOption2","Key":"subOption2","Value":"200"}]
}
one way around it will be to actually encode your json as string in the config file:
"subOptions_take2": "{\"subOption1\": \"subvalue1_from_json\",\"subOption2\": 200}"
then you can just grab it later:
public IndexModel(IOptionsMonitor<MyOptions> options)
{
_options = options.CurrentValue;
var subOptions_string = _options.SubOptions_take2;// this is valid json now: {"subOption1": "subvalue1_from_json","subOption2": 200}
}
I guess, you can use JObject from Newtonsoft.Json package - it's the default JSON parser & serializer in Asp.Net Core
I am new to service stack redis api. So i am getting little confused while using the service stack redis api. I want to know IRedisTypedClient"<"T">"? 1) What stands for "<"T">"? 2) What are the parameters we can pass in the "<"T">"?
The IRedisTypeClient interface provides a typed version of the Redis Client API where all its API's accept a typed POCOs (i.e. Plain Old CSharp Object) for its value body which is in contrast to IRedisClient which just accepts raw strings. Behind the scenes the Typed API's just serialize the POCO's to a JSON string but it's typed API provides a nicer API to work with when dealing with rich complex types.
The API to create a IRedisTypeClient<T> is to use the IRedisClient.As<T> API, e.g:
public class Todo
{
public long Id { get; set; }
public string Content { get; set; }
public int Order { get; set; }
public bool Done { get; set; }
}
IRedisClient redis = redisManager.GetClient();
var redisTodos = redis.As<Todo>();
As seen above you can create a typed API from any user-defined POCO, which now provides API's that lets you work directly native Todo types, e.g:
var todo = new Todo
{
Id = redisTodos.GetNextSequence(),
Content = "Learn Redis",
Order = 1,
};
redisTodos.Store(todo);
Todo savedTodo = redisTodos.GetById(todo.Id);
savedTodo.Done = true;
redisTodos.Store(savedTodo);
"Updated Todo:".Print();
redisTodos.GetAll().ToList().PrintDump();
There's a stand-alone version of this example as well as a Live Demo of Backbones TODO app with a Redis backend which makes use of the RedisClient Typed API.
Apparently my education has failed me, because I didn't realize that methods in C# cannot be serialized. (Good to know.)
I am trying to create a WCF service that returns a simple class I created. The problem is that this simple class contains methods that I want to expose, and the caller of my service won't have any access to them (assuming they won't have a .dll containing the class declaration).
public class Simple
{
public string Message { get; set; }
private const string _Hidden = "Underpants";
public string Hidden
{
get { return _Hidden; }
}
public string GetHidden()
{
return _Hidden;
}
}
I set up a WCF service (let's call it MyService) to return an instance of my Simple class. To my frustration, I'm only getting a partial build of my class back.
public void CallService()
{
using (var client = new MyService.Serviceclient())
{
Simple result = client.GetSimple();
string message = result.Message; // this works.
string hidden = result.Hidden; // this doesn't.
string fail = result.GetHidden(); // Underpants remains elusive.
}
}
Is there any type of workaround where I'm able to set up a property or method on my class that will be accessible to whomever calls my service? How does one handle constants or other methods that are set up in a class that only exists in a service?
Typically you would create three different projects.
1. Service project
2. Client project
3. Data project
The Data project contains only the data classes - no application code. The methods and constants in these data classes should be independent of the Service/Client projects.
The Data project is included as a reference in both the Service and Client projects so that serialization and deserialization happen against the same binary - and you get to retain your constants/methods/etc.
The downside here is that all your clients will either have to be .NET apps, or you will have to provide different data libraries for each platform you wish to support.
As far as I know the only things that can be returned in a WCF service are primitives or a class with public properties that have a get method on them. From a high level WCF exists to allow you to specify a contract between the client and the server that it in theory transportation agnostic (ie you can swap out an HTTP endpoint for a netTcp endpoint and the service will function the same way from a contractual level).
The question to answer then is what data are you trying to pass back in this service call. If it's an object called simple with the data points of Message and Hidden then I would advise creating a data class called Simple that has those values as properties:
[DataContract]
public class Simple
{
[DataMember]
public string Hidden { get; set; }
[DataMember]
public string Message { get; set; }
}
When the client receives the response back Message and Hidden will be populated with whatever you have set their values to on the server side.
The DataMember attribute can only be used on properties and fields. This means that a WCF response can only serialize these types.
If you really want to only use the const in your WCF contract You could convert it to a field and place the DataMember attribute on it:
public class Simple
{
[DataMember]
public string Message { get; set; }
[DataMember]
public const string Hidden = "Underpants";
}
To be able to do this the field must be accessible (public).
Add the DataMember attribute to your property. To do so, you must have both a get and a set defined.
[DataMember]
public string Hidden
{
get { return _Hidden; }
set { }
}
technically you could do
public class thingToSerialize{
public Func<ArgType1,ArgType2...,ReturnType> myFunction{get;set;}
}
and then assign it a lambda that takes the arguments and returns the return type
before serializing
I want to deserialise a JSON response from a Silverlight client.
I have my DTOs in a Portable Class Library, referenced from both server and client.
public class MyDTOResponse
{
public IEnumerable<MyType> ResponseData {get; set; }
}
When I use the ServiceStack C# client (ie NOT from Silverlight), everything works fine: MyType gets hydrated on the client.
From Silverlight, however ResponseData is null.
Simple types work fine from Silverlight also. For example, this works:
public class MyDTOResponse
{
public IEnumerable<string> ResponseData {get; set; }
}
Note: no annotations on the DTOs.
On the client, I am using:
var serviceClient = new ServiceStack.ServiceClient.Web.JsonServiceClient(baseUri);
My work around is to change the DTOs so they use just simple types, then manually hydrate my business objects on the client.
Can I do better than this?
Try adding [DataContract] Attribute to the class MyDTOResponse and [DataMember] Attribute to the Property ResponseData