does anyone know why I can't do this ?
public class CreateScenarioHandler :
GL.RRSL.RequestHandler<CommandRequest<ScenarioProfileData>,
CommandResponse<ScenarioProfileData>>
why is it imposible for Agatha to figure out the type of the generic Request. It is defined there. ?
Type 'GL.RequestResponse.CommandRequest`1[T]' cannot be exported as a schema type because it is an open generic type. You can only export a generic type if all its generic parameter types are actual types.
any ideas of how to do this. It feels so restrictive to have to create a request object for each type of operation.
I'm actually using generic requests/responses successfully.
The trick was to register closed generic requests/responses as known-types.
In order to achieve this, I'm using the following conventions:
generic requests/responses can have only one generic parameter
that generic parameter should has a generic constraint that specifies that it should implement a given interface
I'm using this convention to construct every possible closed generic type
that I'm going to be using as request or response.
For example, I can have something like this:
interface IDtoWithId
{
int Id { get; }
}
public class GetEntityRequest<TDto> : Request where TDto : IDtoWithId
{
....
}
public class UserDto : IDtoWithId
{
public int Id { get; set; }
public string Name { get; set; }
}
Then, when configuring Agatha, I'm using something like
this https://gist.github.com/916352 and doing:
....
configuration.Initialize();
KnownTypeProvider.ClearAllKnownTypes();
KnownTypeHelper.RegisterRequestsAndResponses(typeof(UserDto).Assembly);
The KnownTypeHelper registers the GetEntityRequest type as a
known-type and that allow me to handle that request using a handler
hierarchy like this:
public abstract class GetEntityHandler<TEntity, TDto> :
RequestHandler<GetEntityRequest<TDto>, GetEntityResponse<TDto>>
{
...
}
public class GetUserHandler : GetEntityHandler<User, UserDto>
{
}
I'm using this approach for the CRUD part of an application and it is
working very well.
The problem here has to do with how CommandRequest and CommandResponse are defined.
Agatha looks at the classes which extends Request and Response and add's them to the known types in the WCF.
When the server starts the service, WCF complains that the type CommandRequest is generic and can't be used. WCF if saying that it can't claim to know about a generic type.
When I define CommandRequest and CommandResponse as abstract, and then create classes like ScenarioIORequest/Response which extend CommandRequest and CommandResponse respectively with the apropiate type to be wrapped, WCF does not complain.
It feels like a waste that I have to define specific types when I would like to have generic requests and responses for different DTO. Maybe this will change at some point, but it seams to be WCF issue rather then the Agatha project issue.
Related
In DDD, Value Object and Enumeration are quite beautiful so that I want use both two in the daily program logic, not only domain logic. When use customized value objects and enumerations, serialization problem is coming : should I implemented all the value objects and enumeration with System.Text.Json.JsonConverter<T> , or is there any good way to handle serialization and deserialization ?
Update:
to make it clear, Eumeration demo as below(ValueObject derived classes are same.):
[JsonConverter(typeof(CustomizedConverter))]
public class CustomizedEnumeration1 : Enumeration
{
public string Customized { get; protected set; }
public ... // some other customized property or class
public CustomizedEnumeration(int id, string name, string customized) : base(id, string) {
Customized = customized;
}
}
public class Customized2 : Enumeration
{ ... }
public class OtherCustomized: Enumeration
{ ... }
In DDD, properties sometimes are sealed by protected/private setter, deserialization has no right to set the value. Many derived classes can't deserialize as expected, so we have to rewrite serialization with System.Text.Json.JsonConverter<T> one by one. rewrite every derived Enumeration / Valueobject converter is not good, can any one point out any easy abstraction for that ?
You can achieve your desired result. You need to switch to NewtonsoftJson serialization.
Call this in Startup.cs in the ConfigureServices method:
services.AddControllers().AddNewtonsoftJson();
After this, your constructor will be called by deserialization for classes with private setter.
There is no need for custom converters.
For reference, I am using ASP Net Core 3.1
In protobuf-net (Marc Gravell implementation), is there a way to specify a custom Serializer/Deserializer to be used everytime protobuf encouters a type to be serialized ?
Something like that :
[ProtoContract]
class Foo
{
[ProtoMember(1), ProtoSerializer(BarSerializer)]
public Bar Something { get; set; }
}
class BarSerializer
{
public void Serialize(object value, Protowriter writer)
{
//do something here with writer...
}
}
I looked at the docs but could not find anything.
I know this is possible to use Protowriter directly to serialize an object (like this DataTable example).
What I would like to do is to use the custom serializer only for a given type and use default implementation for the other types already implemented (eg : int, string, ...)
No, basically. But what you can do is write a second type (a surrogate type) that is used for serialization. This type needs to have conversion operators between the two types (declared on either, usually the surrogate), and be registered into the library, for example:
RuntimeTypeModel.Default[typeof(Foo)].SetSurrogate(typeof(FooSurrogate));
The library still controls how FooSurrogate is written on the wire. There is not currently an API that allows you to directly control the output inside a type. But if you start from ProtoWriter you can of course do everything manually.
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
I'm trying to take a datacontract object that I received on the server, do some manipulation on it and then return an upcasted version of it however it doesn't seem to be working. I can get it to work by using the KnownType or ServiceKnownType attributes, but I don't want to roundtrip all of the data. Below is an example:
[DataContract]
public class MyBaseObject
{
[DataMember]
public int Id { get; set; }
}
[DataContract]
public class MyDerivedObject : MyBaseObject
{
[DataMember]
public string Name { get; set; }
}
[ServiceContract(Namespace = "http://My.Web.Service")]
public interface IServiceProvider
{
[OperationContract]
List<MyBaseObject> SaveMyObjects(List<MyDerivedObject> myDerivedObjects);
}
public class ServiceProvider : IServiceProvider
{
public List<MyBaseObject> SaveMyObjects(List<MyDerivedObject> myDerivedObjects)
{
... do some work ...
myDerivedObjects[0].Id = 123;
myDerivedObjects[1].Id = 456;
myDerivedObjects[2].Id = 789;
... do some work ...
return myDerivedObjects.Cast<MyBaseObject>().ToList();
}
}
Anybody have any ideas how to get this to work without having to recreate new objects or using the KnownType attributes?
I think that your problem is that you are trying to send over a generic list.
It will work if you encapsulate the list in an object. That is create an object with a single public property which is the generic list.
You also need to make sure that all classes that are not used directly in the contract are marked as serializable.
If you want to return the derived objects then there will always be a round trip because the client and the service are separate. In order for the client to update its own list of MyBaseObjects it has to deserialize the list of MyDerivedObjects that came from the server.
The use of KnownType and/or ServiceKnownType is needed because this leads to the addition of that type information into WSDL, which is in turn used by the client to deserialize the messages to the correct type.
For starters, a useful tool for testing the scenario you've described: http://www.wcfstorm.com
You might try creating a DataContractSurrogate (IDataContractSurrogate) and returning your base type for the call to GetDataContractType. I'm not really sure that's how it was intended to be used so you still may be better of with "the extra work", but maybe I don't understand the scope of that extra work.
One of the problems with WCF (and .net remoting) is that it they tries to make “message passing” look like method calls.
This fall down when you try to use too many “oop” type designs.
The fact that the messages are
represented by .net classes, does not
make all of their behaviour like .net
class.
See this, and this, for more on the problem of Leaking Abstraction.
So you need to start thinking about message passing not object when designing your WCF interfaces, or you will hit lots of problems like this.
I know that a private parameterless constructor works but what about an object with no parameterless constructors?
I would like to expose types from a third party library so I have no control over the type definitions.
If there is a way what is the easiest? E.g. I don't what to have to create a sub type.
Edit:
What I'm looking for is something like the level of customization shown here: http://msdn.microsoft.com/en-us/magazine/cc163902.aspx
although I don't want to have to resort to streams to serialize/deserialize.
You can't really make arbitrary types serializable; in some cases (XmlSerializer, for example) the runtime exposes options to spoof the attributes. But DataContractSerializer doesn't allow this. Feasible options:
hide the classes behind your own types that are serializable (lots of work)
provide binary formatter surrogates (yeuch)
write your own serialization core (a lot of work to get right)
Essentially, if something isn't designed for serialization, very little of the framework will let you serialize it.
I just ran a little test, using a WCF Service that returns an basic object that does not have a default constructor.
//[DataContract]
//[Serializable]
public class MyObject
{
public MyObject(string _name)
{
Name = _name;
}
//[DataMember]
public string Name { get; set; }
//[DataMember]
public string Address { get; set; }
}
Here is what the service looks like:
public class MyService : IMyService
{
#region IMyService Members
public MyObject GetByName(string _name)
{
return new MyObject(_name) { Address = "Test Address" };
}
#endregion
}
This actually works, as long as MyObject is either a [DataContract] or [Serializable]. Interestingly, it doesn't seem to need the default constructor on the client side. There is a related post here:
How does WCF deserialization instantiate objects without calling a constructor?
I am not a WCF expert but it is unlikely that they support serialization on a constructor with arbitrary types. Namely because what would they pass in for values? You could pass null for reference types and empty values for structs. But what good would a type be that could be constructed with completely empty data?
I think you are stuck with 1 of 2 options
Sub class the type in question and pass appropriate default values to the non-parameterless constructor
Create a type that exists soley for serialization. Once completed it can create an instance of the original type that you are interested in. It is a bridge of sorts.
Personally I would go for #2. Make the class a data only structure and optimize it for serialization and factory purposes.