I'm trying to figure out how all these work together. I know that a DTO is basically just a container of data for the Domain Objects to pass back and forth to forms and such. Does the Domain object contain a DTO or do the DTO and the Domain Object happen to just have all of the same properties that will be mapped manually?
If I am exposing my DTO type in a service, how do I use the getters and setters without creating a round trip for each get/set operation on the client? I know that you can have one long constructor, but that can get ugly if you have more than 7 properties.
When implementing the Repository pattern, do I pass in the DTO or the Domain Object?
The DTO's and the Domain objects should be separate.
There should be a mapper that maps a DTO to a domain object and a domain object to a DTO. This mapper should be an implementation of an interface, with the default mapper using reflection to map the objects to each other.
The repository should be a service that returns the domain objects, which themselves should services.
If the DTO is a class that is exposed by a web service, the WSDL that is created defines the property as an element, and the proxy that gets created on the other side just creates a getter / setter property that is run on the client itself, so the getters and setters do not cause a roundtrip.
Even if you just create a public variable in your DTO, the proxy will be implemented as a getter and setter.
I think it's better to have the DTO contain a reference to the Domain object so that the DTO's consumers can begin using the Domain object. That said, if the DTO's consumers must not mutate the Domain object, you may need to have the DTO contain the values encapsulated in the Domain object. This can be difficult since you may need to do a deep copy of the Domain object.
I'm not sure why it's a problem that exposing a DTO type as a service would cause use of its getters/setters to do a round trip. If the service is a remote service, the returned DTO is serialized anyway and your getters/setters will get the copy of the values. If the service is not remote, it doesn't seem to be much of penalty to do a "round trip" since the client and the service are in the same process space.
Related
I have domain entity Task (it's to do list app) and this entity has a method saveToFile() which takes two arguments - interface ToFileSaver and string fileName. I know this interface should be placed in a domain layer and its implementations in a infrastructure layer but what names should i use for these packages? Ports and adapters?
The parameter types of the entity methods usually belong to these entities. Thus I would place them in the same package as the entity. I would only place them in other packages if they belong to other parts of the domain that belong to another domain concept, e.g. user management.
The implementations are placed outside as you said.
But it seems that you place persistence issues in the domain layer. Instead of giving the entities a Task.saveToFile(ToFileSaver) method you should rather define a TaskRepositoy.persist(Task) method.
The Service Fabric requires [DataContract] and [DataMember] attributes for all the classes that are used as input parameters for the Actor services.
Is there a way to override this default?
In our project we heavily use the read-only message classes, which have read-only properties and constructors. The serialization is handled by Newtonsoft JSON serializer, which works just great. Now, I want to send this messages in Service Fabric, so I need a way to override the default WCF-like serialization to something like JSON serializer.
I was able to make a workaround by implementing the serialization myself. Basically, this is how it works:
Define an actor (+ contract) which accepts and returns byte[] + type name, e.g.
Task<byte[]> DoWork(string typeName, byte[] message);
Deserialize byte[] to an instance of the specified type by using custom serializer (I used Newtonsoft JSON converter).
On the sending side, serialize object to byte[] using the same serializer.
I defined some base classes to wrap that, so I don't have to repeat it for every actor / client.
This feels a bit hacky though. Would be nice to get some opinion from the Service Fabric team. Would be even nicer to get the native extensibility point from the platform itself. DataContract feels a bit archaic, it's not used anywhere in our project anymore.
This approach is described in more details in my blog post.
I don't think this is possible at the minute unfortunately. From this article,
"Reliable Collections allow the serializer to be overridden, but
Reliable Actors currently do not."
So it might be worth mapping to new classes.
In our team, we use the request and response DTO's, through our hierarchy of business logic assemblies (beyond the isolated DB DTO's ).
We have a requirement for no SS dependencies at the business logic layer.
So we don't use the IReturn or IReturnVoid interface. We use only simple c# objects without inheritance.
As for the Routing, we use the Fluent API, in the AppHost.Configure, creating essentially a routing table.
ServiceStack behaves exceptionally well, in our case.
Our Service.Model can be used from the business logic layer, without dependencies.
The service function is a thin wrapper actually, calling the business logic function, to return the response DTO.
But the JsonServiceClient.Get function accepts only as parameter an IReturn object, OR directly the URI.
It does not accept an object as parameter , like the Post function.
Any advice ?
Update 1.
mythz,
About IReturn, unfortunately, in our case there are requirements not using in business logic modules,
even the lighter SS dependency.
The service functions are a thin wrapper calling the business modules.
The link between the two layers are only the Request and Response DTOs. We like very much this approach.
Yes, they are "message operations" but they serve as messages also between the application layers.
Also my clients mainly are Jquery Ajax, not C#. Because of the mobile, the great majority inclined to Jquery Ajax.
So, in our case, we can use only objects, not marked with IReturn. ServiceStack behaves very well.
The API only accepts IReturn<TResponse> to make it clear that it only accepts and works with Request DTO's and not just any DTO or object. Request DTO's are "message operations" and shouldn't be re-used for anything else, the DTO types can be, but not the Request DTO which is your external facing service contract and shouldn't be coupled to any other concerns.
The DTO attributes like [Route], IReturn<T>, [Api], [Restrict], etc are just extra metadata that can't be expressed in C#, but just like defining the type of a DTO property, it's still metadata describing the service, and if you attribute them on the DTO's then they become sharable and introspectable on the client as well. E.g. the ServiceClients will only be able to use the custom routes defined with [Route] because that's the only information clients have, if there are none it will end up falling back to using the pre-defined routes.
ServiceStack encourages defining IReturn<T> markers as it lets you infer more about the service by glancing at the Request DTO, ensures services are restricted in returning the same type (good practice) and centralizes what the Service returns rather than spreading out over the different (more verbose/non-DRY) call-sites, which also means if you change the Response a service returns you'll get compiler feedback on which call-sites needs updating. Not everyone is aware of this info/behavior which is why ServiceStack wants to encourage this "pit of success" development by encouraging the use of IReturn<T> markers, so not everyone has to be.
As for the dependencies, the only dependency your DTO's should need to reference is ServiceStack.Interfaces.dll which is purposely a light-weight, impl-free dll. In v3 this needs to reference the ServiceStack.Common NuGet pkg but for v4 we'll provide a stand-alone ServiceStack.Interfaces NuGet pkg providing the minimum/lightest dependency your DTO's can reference.
I would really like to utilize servicestack for a service I need to write but I'm hitting a mental block wrapping my mind around how it works, and more precisely how I can make it work for my intents and purposes. I don't have a strong asp background, mainly backend, so maybe that's why the mental block.
I have a legacy platform to which I connect via native c++ api. I have warped the native api in cli as a .net class library, this would be my equivalent of the Todo repo being injected in the samples.
The data moving back and forth is exposed in the class lib as value structs. For example account would be defined like this:
struct Account{
int id;
string name;
string password;
...
}
Order would be something like this:
struct Order{
int orderId;
int account;
string comment;
...
}
The lib exposes a lot of functionality and operations for all sorts of different objects defined similarly to the above. What i'm trying to understand is this:
1) How do I register the api with the container? More precisely, I don't understand how the Register method knows what type its supposed to get. In the todo sample everything is defined in the same assembly so its hard to see how the backend gets injected.
2) Is there a way to manage the lifecylce of the back end in the framework. Can I make it a singleton across all connections.
3) Do I have to wrap my structs in classes that map fields to a request. Not quiet clear on how the request objects are defined, it seems that the content of the request should be fields that would translate to urls of fieldname/type for operations. If there is a way to not have to wrap, how do I then limit which fields to expose in the api and which not to.
4)Do I absolutely have to create a service per data type, so in the structures above would I have to implement one service for Orders and one for Accounts of is there a way to combine them into one. I love that ss can be converted to talk over mq's, would making a combined service make it difficult to operate over mq's in the future, what are the cons to this approach.
5) Lastly, I would like to expose operations in the api that, afaik would violate the rest contract. Something like: archive accounts older then.... This would be an operation that returns success/fail status no update/delete ect. Essentially, drive some functionality via an http request. Is this possible in ss, if so, does using it in this way have any debilitating consequences to the framework's operation...
1) To register your API you will want to use the built in IoC with Funq.
container.Register(c => new LegacyApiService())
.ReusedWithin(ReuseScope.Container);
Funq is able to automatically wire these Services in your API Services. Take a look at https://github.com/ServiceStack/ServiceStack/wiki/The-IoC-container.
You can also resolve anywhere container is available using the TryResolve method.
2) You can controls the Object lifetime with Funq by specifing ReuseScopes when you register them. You will want to look at
ReuseScope.Container: Singleton scope
// a instance is used per application lifetime
3) You are going to need to create plan old classes (DTOs) for your structs. This is necessary for ServiceStack. All your DTOs public properties will get serialized. You can also optionally use DataMemberAttribute and the IgnoreDataMemberAttribute to control what public properties get serialized.
4) You will need to have a sservice per request DTO. However, you can keep this code at a minimun and call a centralized business layer. This is necessary since each route + verb needs to have a distinct operation, hence the one service class per DTO.
5) You can easily define more routes and there is nothing that forces you to adhere to REST rules, you are free to implement the HTTP verbs as you see fit. You can easily create specialized routes on GETs that perform an action such as archiving. There are no debilitating consequences here, just perhaps confusion to your API consumers. Just be sure everyone is clear how the API works with documentation.
I found the following in an article: "DAO classes should never be called directly from the client (Services and other consumer classes). The clients should always call the domain objects which in turn should call the DAO's for persisting the data to the data store. ".
This is not how I have seen things done before when doing DDD. Any thoughts on this?
Thanks
That last sentence you quoted from the article could have been written more clearly. I suspect the author meant (emphasis is my added text):
The clients should always call the domain objects which should call the Repository which in turn should call the DAO's for persisting the data to the data store.
"DAO classes should never be called
directly from the client (Services and
other consumer classes). The clients
should always call the domain objects
which in turn should call the DAO's
for persisting the data to the data
store. "
No, I think that is quite wrong.
Domain objects probably shouldn't reference Repositories, either.
If a domain object needs to collaborate with other domain objects, it can raise domain events or take other domain objects as parameters to methods (in which case, the client/caller retrieves all necessary domain objects through repositories).