From your (Domain-) Class to your ModelView-Code, step by step
In some cases it makes sense to not use the Manager.
For instance: Your ModelView-Classes should be based on something else then the
JsModelAttribute (for example a derived class) or you don't need caching and a repository for all your models.
Step 1: Set up the (Domain-) Classes
Your (Domain-) Class will be wrapped with
JsModel<T>.
This makes
creating JsModelMapper-Classes (output-specifications for libraries such as Backbone) easy and straightforward.
Of course you can create an instance of JsModel<T> from scratch.
A better approach is to use the
JsModelBuilder.
It will fill all the Properties, Validations and DefaultValue-lists, as well as the model-name.
If you're (Domain-) class has the
JsModelAttribute, it will also fill in the properties of Url and JsNamespace.
Step2: Get the ViewModel-Code
In
Step 1 I introduced you to the JsModelBuilder.
Now we're using an other builder-class:
JsOutputBuilder.
JsOutputBuilder.ForJsModel has 2 overloads:
- One which takes 2 arguments: the model (IJsModel) and the mapper (IJsModelMapper).
- The second one also needs a JsModelConfig instance. It will place the default JsNamespace in case your IJsModel-instance don't has one.
In any case,
ForJsModel will return you a string-object which is the ModelView-Code any Javascript-Interpreter should understand.
Example
In a nutshell, all you need to know to get the Javascript-output is:
var userModel = JsModelBuilder.Create<User>();
var mapper = new Backbone();
var jsCode = JsOutputBuilder.ForJsModel(userModel, mapper);
You can see a basic (Domain-) Class with the
JsModelAttribute at the
JsModelManager User-Guide-Page.
As described, it is not necessary for the
JsModelBuilder.
Basically you don't need any DataAnnotation whatsoever, but it makes usign this library much more sensible.