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.


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.

Last edited Jul 3, 2013 at 7:16 PM by _RichardFrick, version 5


No comments yet.