Enhanced Form Post Model Binding in Service Stack (like ASP.NET MVC)
For example, in ASP.NET MVC if you have a list of Customer.Orders that you decide to render out on the page using a loop in a Razor View, you can use a naming convention for your html input "name" attribute so that when that form is posted to the server the form data will be properly deserialized/bound to your server Customer.Orders list.
The convention:
input name="Customer.Orders[0].Name"
input name="Customer.Orders[1].Name"
input name="Customer.Orders[2].Name"
So, when this is posted to the server, ASP.NET MVC will create a Default Customer object and then create each Order and bind the Name value from the input and add it to the Customer.Orders list.
It is a nice feature that as far as I can tell is not supported by ServiceStack. Maybe it wasn't as big of a deal before, but now that SS has Razor support and can be used as a full replacement for ASP.NET MVC as well as WCF/WebAPI, it would be a nice to have.
(Background: I have decided to use SS as a replacement and found this issue as I was converting existing views over. I am not sure how many other little differences like this exist. It is probably not easy to identify them, but a comparison chart or conversion chart with this info could be extremely useful to others that are planning on switching completely to SS.)
Zoran
shared this idea
-
ServiceStack does let you plug in your own request binding per type, a small example is at:
-
Wayne Brantley
commented
I agree with you Zoran - if I were to use SS as a complete replacement for razor views, I would need support like the above so it ends up in my models too! The way it works in MVC is really pretty slick. I am not sure if SS 'model binding' is pluggable or not, but if it was you could handle this yourself I would imagine.
-
Zoran
commented
Ok. Thanks.
-
ServiceStack should work "intuitively" not "magically", binding beyond the Service layer is magic and requires internal knowledge of custom HTML form processing in ServiceStack. Already knowing how you would do this in JavaScript is an example of intuitiveness, i.e. it works as expected.
With ServiceStack we're aiming to promote an API-First development model, described briefly in: https://github.com/ServiceStack/ServiceStack/wiki/Release-Notes#api-first-development
i.e. structuring and calling services in a way that works for both HTML and non-HTML native service clients. Using JS allows this, which better enables us to provide useful generic utils to automatically bind normal Service responses to HTML pages. -
Zoran
commented
But it is fine. This isn't a deal breaker for me. It was just convenient to be able to POST list data via the Form and I thought it would also be useful to be able to do that with service stack especially for people who decide to use it as a replacement for ASP.NET MVC as well as WCF/WebAPI.
-
Zoran
commented
I suppose that is a matter of opinion. Here is my thought process on this. I have a page where I need to ask the user a few (dynamic) questions. So I created a Step1Questions DTO that contains a Questions List property (List<Question> Questions). So, the user can use a GET request for Step1Questions and I populate a Step1QuestionsResponse DTO with the questions and then use the SS Razor view engine to render out the questions to the user as a html form. Now, I would like to be able to POST that form to the server and have those questions deserialized into the Step1Questions.Questions list. Doesn't it make logical sense that I should be able to POST this data back to the server using the Form mechanism? I know I can pull it off by getting javascript involved, but why do that, as it requires more code initially and to maintain for the lifetime of the app. One of the main reasons I chose ServiceStack as a replacement is because it just seems to work, almost "magically", and I don't see that as a bad thing. But that's just my opinion.
-
Magic binding and auto populating data models is not something we're looking to promote.
The binding behavior should be clear and intuitive and should only bind to the DTO's (i.e.the external facing service contract). Once populated, the DTO's can then be either saved directly, (i.e. as POCOs with a MicroOrm like OrmLite), or instead mapped it to the data models of the ORM used.
Complex model binding is much easier and more flexible to achieve with JavaScript where you can send complex objects by with serialized JSON using Ajax, or using the QueryString of FormData by passing with the JSV Format, shown in: https://github.com/ServiceStack/ServiceStack/wiki/Serialization-deserialization#passing-complex-objects-in-the-query-string
