This is a general question about the logic behind the naming of the assemblies in a ServiceStack solution.
Please excuse the directness of this question, I am a big fan of the framework but this has been puzzling me for some time so wanted to ask the question and better understand the reason behind the naming.
When creating an ASP.Net Service Host solution named X, I start with the following assemblies:
X
X.ServiceInterface
X.ServiceModel
X.Tests
With consideration to the pure MVC (pure, not asp mvc) naming convention (Model View Control) I am used to sharing the Model and View to a consuming application so that they know how to consume the service and avoid the need to recode the same classes for the model and service proxy, leaving the control code to be consumed by the service provider host. In doing so, the consumer has access to the model and interface (in this case service method signature) without gaining access to the implementation code which may contain sensitive IP.
In the ServiceStack structure, the Model and Method signature (Which I would normally refer to as service interface) is contained in the ServiceModel assembly. While the implementation code of the service is contained in the ServiceInterface assembly.
To me, a better naming convention would be
X
X.ServiceImplementation (Contains implementation code as per now)
X.ServiceInterface (Contains Model and Method signatures, routes etc as per now)
X.Tests
Just a thought and was interested to get some feedback on this.
Yes this makes sense, it’s just when you provide objects to be consumed you want to provide the method signature and the DTOs. I don’t really have a problem with calling this model, I mostly have a problem with calling the other assembly interface, when in fact the interface is being defined in the model assembly.
In any case this is nitpicking, the framework is awesome
The “Service Interface” nomenclature refers to the it being the “facade” or external facing Interface into your System. For many small/medium sized projects, the ServiceInterface project contains both the Service entry points as well as the implementation but for larger Systems they may only contain the entry points which delegate to app logic spread over multiple project subsystems. In either case the “ServiceInterface” project contains the external interface into your system.
Hi Mythz, yes, not that I’m wanting to start a debate on this, but from a purist perspective I think its interesting.
Within ServiceStack the “Service Interface” is defined by the following code for example:
[Route("/applications/{id}", "GET")]
public class GetApplication : IReturn<Application>
{
public Guid ID { get; set; }
public Guid AccountID { get; set; }
}
[Route("/applications", "GET")]
public class GetApplications : IReturn<List<Application>>
{
public Guid AccountID { get; set; }
}
To me, this code alone defines the “interface” of the service and how an external service will “Interface” with the service. It defines the request and response types, names the method and provides the route. This code currently sits in the Model Assembly.
While this code
public object Any(GetApplication request)
{
Application response;
using (var db = DbFactory.Open())
{
CheckTableExistsAndInitialize<Application>(db);
response = db.SingleById<Application>(request.ID);
}
return response;
}
This does not define the interface, it only provides implementation of the interface that has been defined in the model.
An external consuming application, needs the interface definition and the message models in order to know how to connect (e.g. to proxy etc). In soap this is provided by the WSDL, in ServiceStack by your Model assembly. As I mentioned I have no problem with the assembly being named Model, but to me, the Interface assembly is named incorrectly as it does not define the interface, it implements it.
One key points is that the consuming application does not require the Interface Assembly in order to work against the service. That is why in my mind the naming is not quite right on that assembly as in pure OO, the consumer does need to know the providers interface.
The Request DTOs defines the “Service Contract” containing the Request / Response messages sent from the “Client Gateway” to the “Service Interface”, i.e. the facade and the entry point into your System. A visual of what this looks like with respect to your entire system is in Roles of DTOs.
So on one side is the “Client Gateway” which is the implementation that sends Request DTOs to your Service. The implementation for this is realized by the “Service Interface”, i.e. the implementation which accepts Request DTOs sent by the Client Gateway.
This is the nomenclature used to define the Services Gateway pattern, with the “Services Interface” being the server implementation which accepts the Request DTOs, it’s not to be confused with an abstract C# Interface, the “Interface” means the entry point into your System, it’s a Services concept not a code one.
Hi Mythz, firstly thanks so much for taking the time to respond. I wish again to state that I love this framework, it is a beautiful thing.
In my posts I was not referring to an Interface in terms of coding but rather the “View” of a piece of software. For a windows forms app, the interface would be the forms, for a service application the interface is the contract. The interface defines how the outside world interacts with the software.
Application Logic should not be found in an interface assembly. This is because the consuming application should consume the interface (so it knows how to use the service) and sharing of application logic between tiers is not normally a good thing.
You shared above a link to the Service Gateway Pattern, that page links to another link Service Interface Pattern. You will see here in figure 1 that the contract is part of the interface and that the implementation (or application logic) is separate. It makes sense if you think about it because the consuming application must know about two things, the interface and the models (or Model and View in MVC terms). In the context of service architecture, View in my mind is the interface. At present we have the Interface as the Control and that does not seem right to me.
Perhaps in my mind I am expecting the Gateway Pattern to daisy chain to the Interface Pattern, and perhaps you are saying that its one or the other. I’m more than happy to agree to disagree, again I’m in awe of what you have created, I’m a big fan.