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.
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.)
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.
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.
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.
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.