I have groups of DTO classes in separate assemblies so that they can be shared between client/server, and also split across module/plugin boundaries. These are currently implemented as minimal PCL assemblies, and loaded by the server at runtime with “Routes.AddFromAssembly(…)”.
In ServiceStack 3, I was able to keep the DTO Validation logic with the DTOs themselves - actually in the same file, but it looks like the Fluent Validation classes were moved into the main “ServiceStack” assembly (I think it used to be “ServiceStack.Interfaces”?), which is preventing me from bundling the Validation classes in the same assembly as the DTOs since ServiceStack can’t be referenced in a PCL.
Is there any way around this that I’m missing? Of course the obvious workaround is to include the validation classes in separate, non-PCL assemblies.
On a related note: if the validation rules were in the same assembly as the DTOs, the client could potentially perform some validation of a request before attempting to make a round-trip with the server. Is that something that’s already implemented somewhere?
Thanks!
v4 isn’t introducing any limitations, it’s provided PCL packages that are limited to client libraries, but these didn’t exist in v3. The clients which could use v3 server libraries can also use v4 server libraries, you just wouldn’t be using the client PCL packages.
If you need your DTO’s to interoperate between PCL and non-PCL packages you would need to create separate projects with linked source files as seen in the Hello project:
https://github.com/ServiceStack/Hello#sharing-server-dtos-with-clients
The new VS.NET Shared projects feature should make this easier to do in future.
The difference in v3 was that there was no ServiceStack.Interface NuGet package and the Fluent Validation classes were kept in the ServiceStack.ServiceInterface project:
https://github.com/ServiceStack/ServiceStack/tree/v3/src/ServiceStack.ServiceInterface
Which also had a dependency on ServiceStack, but was delivered in the ServiceStack NuGet package.
The difference now is that ServiceInterface project has now been merged into the ServiceStack project which only contains ServiceStack.dll, so there shouldn’t be any extra dependency introduced in v4. v3 also didn’t have PCL packages.
It’s highly recommend that you leave your DTO’s assemblies containing models only and not include any implementation or custom logic which will be coupled to .NET clients. You should think of your DTO’s as your Service Contract and not require access to your services to be coupled with any implementation logic.
ServiceStack does include validation support for Ajax clients which automatically bind server errors to client forms in ss-utils as described here:
https://github.com/ServiceStack/EmailContacts/#fluent-validation
It’s quite responsive because it’s done via ajax/json and avoids full-page reloads. I think you’ll find there’s very little benefit in trying to translate server validation into client validation, i.e. nothing that would justify the added complexity + moving parts translating C# server logic into client-side JS. For cases where you need client side validation, you can add them using the validate: form callback and the $. setFieldError() jquery extension, see:
https://github.com/ServiceStack/ServiceStack/blob/master/release-notes.md#ss-utilsjs
Marc-Antoine Latour:
BTW you could use the project linker plugin this is what we used, even if the description says that this is for silverlight and WPF, it is working for every project type
http://visualstudiogallery.msdn.microsoft.com/273dbf44-55a1-4ac6-a1f3-0b9741587b9a
Phillip Powers:
Thanks Demis for the info and the pointer to the AJAX stuff.
I’m totally on-board with the DTOs in a separate assembly as a service contract, and that’s how we have it setup. In my mind, though, the validation is actually part of that contract.
For the client-side validation, I’m actually building Xamarin/MVVMCross clients right now, which is where I would intend to re-use that code.
I guess the general question is whether the Fluent Validation stuff is able to be put into PCL assemblies for those two reason: keeping the validation logic together with the DTOs, and possibly actually using it in C# clients - and it seems the answer is “no”?
This certainly isn’t any sort of deal-breaker for any of our stuff (we can work around it), it’d just be one of those “nice to have” things.
As always, thanks for the response and high quality work.