ASP.NET Web API Knockout Validation

Question

I have a question related to client validation using knockout and ASP.NET web API. I want the views to be completely static (there might be a root index.html / cshtml exception), and I don't want to repeat myself by writing the rules for data annotation attributes in js by hand.

My context is the average size (~ 20-40 objects with a biz layer) on Durandal.

Unsuccessful / inappropriate ways I found and their explanation:

1. Use Breeze.js

At first glance, Breeze.js looks exactly what I need. How it works: it passes the json via / Metadata link, then maps it to the knockout.valudate plugin . Everything is fine, but the separation of entities looks strange to me (I need to forget about Nunit, complex server logic, etc. And it's just scary to make your datacontext public: insecure, not data safe!). The save method with a JObject argument also looks weird to me.

2. Get data from web api, metadata from Breeze or Web Api (how?) And convert it to client

The only solution that I find close to this is the following: https://github.com/johnculviner/FluentKnockoutHelpers . It displays ALL (this is not so important, but not very good from my point of view) metadata in cshtml, then it maps it to knockout.validate. Maybe it looks like a ready-to-use framework with similar functionality, where can I get matadata from api via json and knock it out?

3. Render cshtml in html on build

Comprehensive assembly process!

Perhaps you have another solution for static HTML and Web API applications?

Answer 1

To begin with, we must first agree on one thing -

Getting data from the server using Breeze can be tricky to configure for the first time if you are not familiar with JavaScript

Let's look at a few reasons and examples of how to overcome this problem, or skip unnecessary reading and talking about security when using Breeze.js or any client 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 documents on breeze.js are always updated and improved, but as a community, we could improve to learn more about how to use breeze.js. Here are a few hints and some basic breeze.js configuration scripts in your client application -

Main scenarios

• Retrieving data from a web API controller action -

  You can set Breeze.js to use your own metadata when using the web API route -

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

• Getting data from a web API controller action using EF / Breeze.WebApi

  You can install Breeze.js to use ASP.NET MVC 5 / Web API 2 projects in VS2012 / 13. If you want to see how to use the server-side Breeze.WebApi as an assistant, check the links on this list or on online education sites such as PluralSite.com -

  http://www.breezejs.com/samples

  http://www.pluralsite.com

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

• Learning how the Breeze works -

  http://learn.breezejs.com/

• Hitting a server from your SPA that is completely untied -

  Why constantly spend time creating your own data library on the client side and creating graphs of objects or using mapping libraries that do not glow quickly? JavaScript ORM is fast becoming fury because why do I need to rebuild the wheel? How can a breeze do this?

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

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

  Two excellent examples where a fully decoupled API can be used by technology on the client side without linking client information to any specific server-side stack.

Why is Breeze.js safe?

You should never expose any data to the outside world no matter what it is and how it is created. If you have a client-side or server-side application that does not authenticate users before returning data, how can you ensure that you authenticated correctly before looking at client-side technologies?

How about sending data using saveChanges ()?

There are very few situations in which I would develop an application that would give the browser a free rome for publishing / updating my database. Perhaps if the content was changed, it was in a very early development cycle, where I tested the receipt and publication of data, and the business layer and what it allowed (probably verified using unit testing) was configured to provide unlimited readability / data records.

But what about moving the browser-based application?

I would never put my signature on a document that I did not read, and was / 100% sure that the document is ready for signing. I would also never transfer code from a development or QA environment to a production environment, without guaranteeing that my requirements are met taking into account the technologies that I use. If using ASP.NET MVC and a session to store user information is the direction your application should follow, and then decorate your controller’s actions with the [Authorize] attribute. If you have another form of security, you must always maintain the appropriate levels of security for the data you expose.

Never trust a browser application to provide you with non-malicious content, even 99.99% of the time. 0.01% may be the straw that broke the camel.