ASP.NET Web API knockout validation

Question

I have a question related with client validation using knockout and ASP.NET Web API. I want the views will be completely static (may be excluding root index.html/cshtml) and I don't want to repeat myself by writing data annotations attributes rules in js by hands.

My context is a mid-size (~20-40 entities with biz layer) app on Durandal.

Unsuccessful/unappropriate ways I found and their explanation:

1. Use Breeze.js

At first view, Breeze.js looks like exactly what I need. How it works: it shares json via /Metadata link, then it maps one to knockout.valudate plugin. Everything is fine, but sharing the entities looks weird for me (I need to forget about Nunit, complex server logic and so on...And it is just scary to make your datacontext public: insecure and not data-safe!). Saving method with JObject argument also looks strange for me.

2. Get data from web api, metadata from either Breeze or Web Api (how?) and transform it on client

The only solution I find close to this it is this one: https://github.com/johnculviner/FluentKnockoutHelpers . It renders ALL(it is not so crucial, but is not good from my point of view) metadata it in cshtml, then he maps it for knockout.validate. May be there it a similar ready to use framework with similar functionality where I can get matadata from api via json and provide in knockout?

3. Render cshtml in html on build

Complex build process!

May be you have another solutions for static HTML and Web API applications?

Answer 1

For starters, we have to be in agreement about one thing first -

Getting Data from the server using Breeze can be tricky to set-up the first time if you aren't experienced in JavaScript

Let's either look a few reasons why and examples on how to overcome that challenge, or skip over the non-required reading and talk about security when using Breeze.js or any client-side application -

<!--
    If you think this next section is 'Too Long' : 'Don't Read'
        and are just interested in security, skip down until
        you see 'Why is Breeze.js secure?'
-->

<section role="TL:DR">

The docs on breeze.js are always updating and improving but as a community we could improve to learn more about how to leverage breeze.js. Here's a few ways to hints and some basic scenarios of how to set up breeze.js in your client-side application -

Basic scenarios

1. Getting data from a Web API Controller Action -

   You can set Breeze.js up to use it's own metadata when consuming a Web API route -

   http://www.breezejs.com/documentation/web-api-routing http://pluralsight.com/training/Courses/TableOfContents/building-single-page-applications-breeze

2. Getting data from a Web API Controller Action with EF / Breeze.WebApi

   You can set Breeze.js up to use ASP.NET MVC 5 / Web API 2 Projects in VS2012/13. If you want to see how to utilize the server-side Breeze.WebApi as a helper check the links within this list or on online education sites like PluralSite.com -

   http://www.breezejs.com/samples

   http://www.pluralsite.com

   In the samples you will find how to use a good 85% of currently used web technologies. This includes Angular, Durandal, MongoDb, Node, Entity Framework, Require, Knockout, Ruby, Twitter Bootstrap, Backbone, etc..., etc...

3. Learning how Breeze works -

   http://learn.breezejs.com/

4. Hitting a server from your SPA that is completely decoupled -

   Why spend all the time setting up your own client-side data library and creating object graphs or using mapping libraries that aren't lighting fast? JavaScript ORM's are quickly becoming all the rage because why keep rebuilding the wheel? How can Breeze do it?

   http://www.breezejs.com/samples/edmunds

   http://www.breezejs.com/samples/espn

   Two great examples where completely decoupled API's can be consumed by client-side technology without tying the client-side stuff to any certain stack on the server-side.

Why is Breeze.js secure?

You should never expose any data to the outside world regardless of what it is or how it is generated. If you have an application on the client-side or the server-side that isn't properly authenticating it's users before returning data than how can you ensure you were properly authenticating before looking at client-side technologies?

What about when posting data back with saveChanges()?

There are very few situations in which I would design an app that gave a browser free roam to post / update my database. One might be if the content being changed was in very early development cycles where I was testing getting and posting data, and the business layer and what it allowed (probably verified through unit testing) was set up to allow unrestricted read/write of the data.

But what about moving a browser-based application to production?

I would never put my signature on a document that I didn't read over and was / am 100% sure that the document was ready to be signed. I would also never pass code from a dev or QA environment into a production environment without ensuring that my requirements were being met given the technology stack I am using. If using ASP.NET MVC and Session to store user information is the direction your application should take, then decorate your controller actions with the [Authorize] attribute. If you have another form of security then you need to always maintain proper security levels of the data you are exposing.

Never trust a browser-based application to provide you non-malicious content, even 99.99% of the time - the .01% could be the straw that broke the camel's back.