Tuesday, 21 May 2013

Simple CRUD with Knockout, Breeze, WEB API, Twitter bootstrap and the technologies we used in the previous post.

Hello,

Previous Post: Build application using ASP.NET MVC 4, WEB API, EF 5.0 (database first) Knockout (MVVM pattern), Breezejs, KoGrid, Autofac,...

As I was asked to write a post with simple Insert/Update/Delete screens using the same technology from my previous post here is what I came with. I've got to say that this is a very busy period in my life so I couldn't spend too much of my time writing this post but hopefully it wont affect the quality of the solution. The idea was to make this CRUD screens as a single page interface. We'll start from the project we've already made in the previous post. The source can be found here. First instead of going straight to the page as we did in previous post we'll build a home/welcome page with a simple menu where we can choose where we want to go (either the page we've built in the last post (TaxPayer) or the new page we are building now - Declaration). To go to the home by default we'll change RouteConfig and instead of TaxPayer controller we put Home.

Twitter bootstrap

To build a good design easily I will be using Twitter bootstrap. Actually I'll be using much more of the Twitter bootstrap than the nice styling (e.g. Modal plugin, menu,...) and I would recommend you to try it also. For those who doesn't know what the Twitter bootstrap is you can find out here. In simple words twitter bootstrap is a front-end framework with a set of predefined styles and bunch of java script plugins that can help you to build nice looking and efficient web app in a simple manner. To start we download twitter bootstrap, unzip it and add styles and javascript files to the project (both minified and developing version).

 

Then we add them to the bundle configuration file as we did in the previous post:
 
 
 

Build Menu

After this is done we'll edit our layout page and TaxPayer page (as we'll move out some of the javascript file that were referenced before in layout page but they are actually TaxPayer specific). After we do that our layout page looks like this:
 

 <!DOCTYPE html>  
 <html>  
 <head>  
   <meta charset="utf-8" />  
   <meta name="viewport" content="width=device-width" />  
   <title>@ViewBag.Title</title>  
   @Styles.Render("~/Content/css")  
   @Scripts.Render("~/bundles/modernizr")  
   @Scripts.Render("~/bundles/jquery")    
   @Scripts.Render("~/bundles/logger")  
   @Scripts.Render("~/bundles/bootstrap")  
   @Scripts.Render("~/bundles/knockout")  
   @Scripts.Render("~/bundles/koGrid")  
   @Scripts.Render("~/bundles/q")  
   @Scripts.Render("~/bundles/breeze")
  
 </head>  
 <body>  
     <div class="navbar navbar-fixed-top">  
    <div class="navbar-inner">  
     <div class="container">  
      <a class="btn btn-navbar" data-toggle="collapse" data-target=".nav-collapse">  
       <span class="icon-bar"></span>  
       <span class="icon-bar"></span>  
       <span class="icon-bar"></span>  
      </a>  
      <a class="brand" href="/">Babic's Tax Blog Application</a>  
      <div class="nav-collapse">  
       <ul class="nav">  
        <li class="active"><a href="/">Home</a></li>         
        <li class="dropdown">  
         <a class="dropdown-toggle" data-toggle="dropdown" href="#">Maintenance<b class="caret"></b></a>  
         <ul class="dropdown-menu">  
           <li><a href="/TaxPayer">Tax Payer</a></li>  
           <li><a href="/Declaration">Tax Declaration</a></li>  
         </ul>  
        </li>  
        </ul>  
      </div><!--/.nav-collapse -->  
     </div>  
    </div>  
   </div>  
   <article role="main">
  
     @RenderBody()  
   </article>    
   @RenderSection("scripts", required: false)  
   <!-- Le javascript  
   ================================================== -->  
   <!-- Placed at the end of the document so the pages load faster -->  
   <script>  
     $().ready(function () {  
       $('.dropdown-toggle').dropdown();  
       $(".collapse").collapse();  
       $(".alert").alert();  
     });  
   </script>  
 </body>  
 </html>
  
 
and TaxPayer looks like this:
 
 @{   
   ViewBag.Title = "Index";   
  }   
  <!DOCTYPE html>   
  <html>   
  <body>   
   <div id="body">   
    <div id="imageWrapper" align="center">   
     <img id="loader" src="images/ajax-loader.gif" data-bind="visible: hide()" />   
    </div>   
    <div id="gridWrapper" data-bind="visible: !hide()">   
     <div id="sandBox" style="height: 200px;" data-bind="koGrid: { data: people,   
      columnDefs: [{ field: 'FirstName', width: 100 },   
           { field: 'FamilyName', width: 110 },   
           { field: 'BirthDate', width: 100 },   
           { field: 'Profession', width: 100 },   
           { field: 'Telephone', width: 100 },   
           { field: 'Address', width: 150 },   
           { field: 'City', width: 100 },   
           { field: 'Country', width: 100 },   
           { field: 'Email', width: 150},   
           { field: 'Twitter', width: 110 }   
      ],   
        autogenerateColumns: false,   
        isMultiSelect: true,  
        enablePaging: false }">   
     </div>   
    </div>   
   </div>   
 @Scripts.Render("~/bundles/app")  
  </body>   
  </html>   
 
Now we change the Home/Index page and add background picture and we've got our home page and simple drop down menu :)
 

 
 

Server side

Finally we can start building our CRUD functionality. We'll be doing it for the Declaration screen. The Declaration screen contains declaration name, which year the declaration is valid for and declaration note do user can write note related to that declaration. After we added the table to the Entity Framework model, the diagram looks like:
 
Now we'll write some code to bring data from server to the client ( we'll go fast through this as we did exactly the same stuff in the previous blog). First we'll create Repostiory for Declarations.

IBreezeDeclarationRepository:
 
 using System; 
 using System.Collections.Generic;
 using System.Linq;
 using System.Text;
 using System.Threading.Tasks;
 using Breeze.WebApi;
 using Newtonsoft.Json.Linq;
  
 namespace TaxAppBlog.Models.Contracts
 {
   public interface IBreezeDeclarationRepository  
   {
     IQueryable<Declaration> Declarations { get; }
     string Metadata();
     SaveResult SaveChanges(JObject saveBundle);  
   }  
 }  

BreezeDeclarationRepository:
 using System;  
 using System.Collections.Generic;  
 using System.Linq;  
 using System.Web;  
 using Breeze.WebApi;  
 using Newtonsoft.Json.Linq;  
 using TaxAppBlog.Models.Contracts;
  
 namespace TaxAppBlog.Models.Implementations  
 {  
   public class BreezeDeclarationRepository : IBreezeDeclarationRepository  
   {  
     readonly EFContextProvider<TaxEntities> _contextProvider =  
   new EFContextProvider<TaxEntities>();  
     public IQueryable<Declaration> Declarations  
     {  
       get { return _contextProvider.Context.Declarations; }  
     }
  
     public string Metadata()  
     {  
       return _contextProvider.Metadata();  
     }
  
     public SaveResult SaveChanges(JObject saveBundle)  
     {  
       return _contextProvider.SaveChanges(saveBundle);  
     }  
   }  
 } 

Notice that we have only one property - Declarations and one method - SaveChanges,  Metadata is already explained in the previous post. SaveChanges method is coming out of box for the entity framework (EFContextProvider). The signature is JObject which is a JSON.NET representation of the change-set data. How this works we'll see more later but simple explanation would be: The Breeze EntityManager tracks entities and it tracks all the changes. When we call saveChanges , the manager will send it to the controller's SaveChanges method and controller through repository calls EFContextProvider SaveChanges.
Before we create controller we'll tell to our DI container to inject anything that implements our new repository interface (AutofacConfig):



Now we are ready to build our Breeze Controller:

 
 using System;  
 using System.Collections.Generic;  
 using System.Linq;  
 using System.Net;  
 using System.Net.Http;  
 using System.Web.Http;  
 using Breeze.WebApi;  
 using Newtonsoft.Json.Linq;  
 using TaxAppBlog.Models;  
 using TaxAppBlog.Models.Contracts;  
 namespace TaxAppBlog.Controllers  
 {  
   [BreezeController]  
   public class BreezeDeclarationController : ApiController  
   {  
     IBreezeDeclarationRepository repository;  
     public BreezeDeclarationController(IBreezeDeclarationRepository repository) 
     {  
       this.repository = repository;  
     }
  
     public IQueryable<Declaration> GetDeclarations()  
     {  
       return repository.Declarations;  
     }
  
     // ~/api/BreezePeople/Metadata   
     [HttpGet]  
     public string Metadata()  
     {  
       return repository.Metadata();  
     }
  
     [HttpPost]  
     public SaveResult SaveChanges(JObject saveBundle)  
     {  
       return repository.SaveChanges(saveBundle);  
     }  
   }  
 }  

Client side

We are pretty much done with the server side so lets go and create ViewModel on the client. This time I won't separate breeze and Knockout in two files (as I did in the previous post) but put altogether in one. I will start with only getting Declarations and then adding bit by bit of CRUD functionality (you'll see it's nice and simple). At the begining view model will expose only GetDeclarations and SaveChanges (see below).

 DeclarationViewModel.js
 
 
(function (root) {  
   var breeze = root.breeze,  
     ko = root.ko,  
     app = root.app = root.app || {};  
   Logger.show();        // show logger initially  
   log("Window is loaded.");
  
   // define Breeze namespace  
   var entityModel = breeze.entityModel;
  
   // service name is route to the Web API controller  
   var serviceName = 'api/BreezeDeclaration';
  
   // manager is the service gateway and cache holder  
   var manager = new entityModel.EntityManager(serviceName);
  
   // define the viewmodel  
   var vm = {  
     declarations: ko.observableArray(),  
     save: saveChanges  
   };
  
   // start fetching Declarations  
   getDeclarations();
  
   // bind view to the viewmodel  
   ko.applyBindings(vm);
  
   function getDeclarations() {  
     log("querying Declarations");  
     var query = entityModel.EntityQuery.from("GetDeclarations");  
     return manager  
       .executeQuery(query)  
       .then(querySucceeded)  
       .fail(queryFailed);
  
     // clear observable array and load the results   
     function querySucceeded(data) {  
       log("queried Declarations");  
       vm.declarations.removeAll();  
       var declarations = data.results;  
       declarations.forEach(function (declaration) {  
         vm.declarations.push(declaration);  
       });  
     }  
   };  
  
   function saveChanges() {  
     return manager.saveChanges()  
       .then(function () { log("changes saved"); })  
       .fail(saveFailed);  
   }
  
   function queryFailed(error) {  
     log("Query failed: " + error.message);  
   }
  
   function saveFailed(error) {  
     log("Save failed: " + error.message);  
   }
  
 }(window));  
 
Add the DeclarationViewModel to the BundleConfig ( bundles.Add(new ScriptBundle("~/bundles/declaration").Include("~/Scripts/App/DeclarationViewModel.js"));). Now we create mvc controller DeclarationController and its view Index (both are very simple).
 
Index.cshtml
 
 
@{  
   ViewBag.Title = "Tax Declarations";  
 }  
 <!DOCTYPE html>  
 <html>  
 <body>  
   <table id="taxDeclarations" class="table table-striped table-hover table-condensed">  
     <thead>  
       <tr>  
         <th>Declaration Name</th>  
         <th>Declaration Year</th>  
         <th>Declaration Note</th>  
       </tr>  
     </thead>  
     <tbody id="declarationList" data-bind="foreach: declarations">  
       <tr>  
         <td>           
           <span style="color: darkgrey; font-size: 10pt; font-weight: bold" data-bind="text : DeclarationName"></span>  
         </td>  
         <td>  
           <span style="color: darkgrey; font-size: 10pt; font-weight: bold" data-bind="text : DeclarationYear"></span>  
         </td>          
         <td>  
           <span style="color: darkgrey; font-size: 10pt; font-weight: bold" data-bind="text : DeclarationNote"></span>  
         </td>  
         <td>  
           <button class="declarationDeleter btn btn-danger">  
             Delete  
           </button>  
         </td>  
       </tr>  
     </tbody>  
   </table>    
   @Scripts.Render("~/bundles/declaration")  
 </body>  
 </html>  
When we run the application and choose Declaration option in the menu the Declaration screen appears and we got listed the existing Declarations. Notice that we added a call to the our view model script file through the following line: @Scripts.Render("~/bundles/declaration"). Now we are ready for: adding new Declaration/editing Declaration/deleting Declaration:

Add New Declaration

So the idea is that when the user clicks on button "Add Declaration" the modal window will pop up and let user to fill in the form and save it. In the View Model we'll expose the observable entity newDeclaration and the method addDeclaration. The observable newDeclaration will be bound on the controls on the modal window. The function addDeclaration would create breeze entity based on the newDeclaration, push it to the observable list and call save method. So we add the following markup to the declaration/index view:
 
   <div class="pull-right">  
     <a id="new-taxDeclaration" class="btn btn-success"  
       data-toggle="modal" href="#taxDeclaration-modal">Add Declaration</a>  
   </div>  
   <div class="modal hide fade" id="taxDeclaration-modal">  
     <div class="modal-header">  
       <button type="button" class="close"  
         data-dismiss="modal">  
         ×</button>  
       <h3>tax Declaration</h3>  
       <div class="row offset1">  
         <p>  
           <label>Declaration Name</label>  
           <input type="text" data-bind="value :newDeclaration().DeclarationName" />  
         </p>  
         <p>  
           <label>Declaration Year</label>  
           <input type="text" data-bind="value :newDeclaration().DeclarationYear" />  
         </p>  
         <p>  
           <label>Declaration Note</label>  
           <textarea data-bind="value :newDeclaration().DeclarationNote"></textarea>  
         </p>  
       </div>  
       <div class="modal-footer">          
         <a href="#" data-dismiss="modal" class="btn btn-primary declarationAdd" data-bind="click : addDeclaration">Save</a>  
         <a href="#" data-dismiss="modal" class="btn">Cancel</a>  
       </div>  
     </div>  
   </div>  
 
As mentioned above in the viewmodel we expose newDeclaration and AddDeclaration:
 
  // define the viewmodel  
   var vm = {  
     declarations: ko.observableArray(),  
     save: saveChanges,  
     newDeclaration: ko.observable(  
       {  
         DeclarationName: "",  
         DeclarationYear: "",  
         DeclarationNote: "" 
       }),  
     addDeclaration: addNewDeclaration  
   };
  
   function addNewDeclaration() {  
     var item = createDeclaration({  
       DeclarationName: vm.newDeclaration().DeclarationName,  
       DeclarationYear: vm.newDeclaration().DeclarationYear, 
       DeclarationNote: vm.newDeclaration().DeclarationNote  
     });  
     vm.declarations.push(item);  
     vm.save();  
   };
  
   function createDeclaration(newDeclaration) {  
     return manager.createEntity('Declaration', newDeclaration);  
   };  
 
And now we can create new Declaration :)


This is all good but we are kind of back to old days where you've got button click handler on your form (view) and we don't want that, we want to be unobtrusive :). First in the Index view remove the data binding on the button "declarationAdd" (data-bind="click : addDeclaration") then in the view model attach the handler on the button click using the JQuery .delegate().
 
   $(document).delegate(".declarationAdd", "click", function () {  
     log("Adding New");  
     vm.addDeclaration();  
   }); 
 
 
Now we are done with adding new declaration. Have in mind that this is only for demo purposes (here is missing a lot of stuff e.g. validation before saving, etc...)

Edit/Update Declaration

To edit declaration I'll be using twitter bootstrap modal dialog again.  When user double-click on the declaration name the modal dialog will appear (Bootstrap makes it really easy for us when it comes to the modal windows. Initially the modal window is hidden and to show it we can use either a link or the button. You can activate modal windows in two ways: by using data attributes or using java script. Here I am using java script....) and after changing whatever needs to be changed, the user can save it to the database or cancel the changes.
In the view we change the table cell for declaration name - it becomes:
 
 <td class='value editable'>  
           <div class="editor modal hide">  
             <div class="modal-header">  
               <h3>Edit Children</h3>  
             </div>  
             <div class="row offset1">  
               <p>  
                 <label>Declaration Name</label>  
                 <input type="text" data-bind="value :DeclarationName" />  
               </p>  
               <p>  
                 <label>Declaration Year</label>  
                 <input type="text" data-bind="value :DeclarationYear" />  
               </p>  
               <p>  
                 <label>Declaration Note</label>  
                 <textarea data-bind="value :DeclarationNote"></textarea>                  
               </p>  
             </div>  
             <div class="modal-footer">  
               <a href="#" data-dismiss="modal" class="btn declarationCancel">Cancel</a>  
               <a href="#" data-dismiss="modal" class="btn btn-primary declarationSaver">Save</a>  
             </div>  
           </div>  
           <span style="color: darkgrey; font-size: 10pt; font-weight: bold" data-bind="text : DeclarationName"></span>  
         </td>  
 
Again we want to be unobtrusive ;). In the view model we'll expose the method editDeclaration the we'll attach handlers for showing modal window, saving and cancelling changes. The ViewModel and the editDeclaration function would look like this:
 
  var vm = {  
     declarations: ko.observableArray(),  
     save: saveChanges,  
     editDeclaration: editDeclaration,  
     newDeclaration: ko.observable(  
       {  
         DeclarationName: "",  
         DeclarationYear: "",  
         DeclarationNote: ""  
       }),  
     addDeclaration: addNewDeclaration  
   };
  
   function editDeclaration(declaration) {  
     declaration.entityAspect.setModified();  
     vm.save();  
   }  

We mark the entity to an EntityState of 'Modified'. Here I am not sure that I should be doing it manually but really have no time to investigate further. If someone finds better way please let me know. Now we can add the code for our handlers:
 
  $("#declarationList").delegate(".editable", "dblclick", function () {  
     $(".modal", this).modal();  
   });  
   $("#declarationList").delegate(".declarationSaver", "click", function () {  
     log("sad ga lomi...:)");  
     var declaration = ko.dataFor(this);  
     vm.editDeclaration(declaration);  
   });
  
   $("#declarationList").delegate(".declarationCancel", "click", function () {  
     log("cancel");  
     var declaration = ko.dataFor(this);  
     declaration.entityAspect.rejectChanges();  
   });  
 
Here there are a couple of interesting points. First you might notice that we are using ko.dataFor(this) (using parameter "this"). It returns the data that was available for binding against the element.Or in another words what the ko.dataFor(this) function gives you is the object for which an element is bound to. The other interesting thing is that user might want to cancel all the changes (click the cancel button :)) Here the breeze comes very handy: the function rejectChanges() - cancel pending changes, revert properties to their prior values, and set the entityState to "Unchanged". If you are working with pure Knockout than you would probably want to use this simple editor pattern which allows users to accept or cancel their changes. But using breeze this become very trivial :). Here we are done with editing of our entity (declaration) :)

Delete Declaration

And the last thing we are going to do in this exercise is to delete declaration. In the Index view in the table we already added the button to delete declaration (declarationDeleter) and in the ViewModel we'll expose the method deleteDeclaration then we'll attach handler for deleting the Declaration (remember - be unobtrusive). The ViewModel and the deleteDeclaration function would look like this:
 
  var vm = {  
     declarations: ko.observableArray(),  
     save: saveChanges,  
     deleteDeclaration: deleteDeclaration,  
     editDeclaration: editDeclaration,  
     newDeclaration: ko.observable(  
       {  
         DeclarationName: "",  
         DeclarationYear: "",  
         DeclarationNote: ""  
       }),  
     addDeclaration: addNewDeclaration  
   };
  
   function deleteDeclaration(declaration) {  
     declaration.entityAspect.setDeleted();  
     vm.declarations.remove(declaration);  
     vm.save();  
   }  
 
Here as well I needed to "announced" that my entity is for deletion. This is the same thing as above for the modified entity. We mark the entity to an EntityState of 'Deleted' and entity is scheduled for deletion during the next Save call.
On the end you see it is very easy to build CRUD with knockout, breeze, asp.net mvc4, twitter bootstrap, autofac,... The performances should always be good as the only communication back to the server is to save stuff to the database. I will mention once again that this is not production code (far from it: no validation, etc...)
Here you can find the small video of what we have built in this blog post.

video

The source code with all the changes from this post you can find in the github (commit from 21st May 2013) => here

Sunday, 10 March 2013

Build application using ASP.NET MVC 4, WEB API, EF 5.0 (database first) Knockout (MVVM pattern), Breezejs, KoGrid, Autofac,...

Next Post(Continuation of this post): Simple CRUD with Knockout, Breeze, WEB API, Twitter bootstrap ,...

Hello,

As mentioned in my introductory post, English is not my mother tongue and so before I really start writing anything, I have to apologize in advance for any language mistakes I make.
Now let's start.

INTRODUCTION

So here today I'll build the application using the following technologies: ASP.NET MVC 4, Entity Framework 5.0, ASP.NET WEB API, AUTOFAC (DI container) and the following JavaScript frameworks: BreezeJS, JQuery, KnockoutJs, KoGrid,... Bear in mind that this is only for learning purposes! As I want to build a Tax calculation app, this will be a small excerpt of it, but showing the complete architecture (with only one screen : Tax payer screen). The purpose of this post is to show how easy (and clean and elegant) it is to get data from the server and bind them on the client using MVVM pattern and all the technologies I've listed above. Of course, along the way I'll try to convince you to use DI containers and couple of other techniques.
I'll try to go into details and do it as simply as I can, so even fresh new developers can understand what I am trying to say. The source code can be found at the github. So please take it, play with it, extend it...feel free to change it in any way and let me know what you think about it. The project is built using Microsoft Visual studio 2012 and SQL Server 2008R2, if you use Visual studio 2010 then you'll have to add yourself MVC4 templates.
So in short we have a simple UI with a grid (KoGrid) that is bound to ViewModel (Knockout observable collection). In the ViewModel we reference breezeJS data service which is querying data from our persisting service. That would all happen on the client side, while on the server side we set our persisting service which is ASP.NET Web API and by using Breeze.NET API and Repository pattern we request data from our model which is Entity Framework. The dependecies are managed by Autofac DI container. For the debugging purposes I have used a simple logger class.
The architecture that I am trying to build looks like the figure below.


Tax payer application architecture

SERVER

ASP.NET MVC 4

I chose the ASP.NET MVC. Why do I like the ASP.NET MVC? The list is long, but the first things that come to mind are: Separation of concerns, Testability, URL Routing, Built-in and shipped JQuery support :), WEB API (MVC-like framework that we can use to create a RESTful service), good mobile support, etc... The MVC lets you separate business logic from presentation logic so that they can be independently tested. It also lets you easily extend your application or replace any of the components as they are independent of each other.
In my example, everything will be a part of the same project even though they can and they should be sitting in the separate assemblies (e.g. WEB API, EF,...).
So lets start. Run your VS2012 - choose ASP.NET MVC 4 template - type the name of the project (TaxAppBlog). If you want to learn more about ASP.NET MVC 4 - David Hayden is writing a nice tutorial on his blog.



After you clicked ok, the new screen came up and there we choose the WEB API template.


ASP.NET WEB API

It is, in my humble opinion, a huge step forward to make simple SOA architecture available to anyone. You remember the time when people started talking about SOA, it was a huge buzz word. You couldn't pass by any meeting room without hearing somebody mentioning it. Using services in your application was a powerful idea but making your code become available through services required learning different frameworks and doing a lot of plumbing  and configuration to make it work. The learning curve was high, the apps that came out were brutal and the market was full of the proprietery technologies to make this happen, including WCF. With all this in mind Microsoft finally produced the framework that uses only open standards and is very easy to set it up and use. So here are a couple of bullet points on ASP.NET WEB API.
  • It is a framework for building pure HTTP based services, where the request and response happens with HTTP protocol.
  • It is an ideal platform for building RESTful applications on the .NET Framework.
  • Next iteration of WCF REST
  • Incorporated into ASP.NET MVC 4
  • Uses HTTP protocols
  • Using REST to consume the service. Basic URL + HTTP method (GET, PUT, POST, DELETE).
In my example I am going to use WEB API to get data and send it to the client in JSON format. The format of the returning data can be requested differently (instructions in the Accept Header). I am not going to explore much more on WEB API here (not the main purpose of this post) but if you want to learn more, than the best place to start is here.
After the visual studio finishes creating a project, the solution explorer will look like picture below.


Notice that there are two controllers created by default: Home and Values controller. The differences between them is that Home is inherited from System.Web.Mvc.Controller and Values from System.Web.Http.ApiController. If you are familiar with ASP.NET MVC then you already know how the Routing works. If I can explain it in one sentence then I would probably say that it is an interpretation of URLs  by the server to decide what code should handle the request. The difference with ApiControllers is that the actions are not defined by URL but by HTTP methods so the same URL can contain two different HTTP methods, therefore they do two different actions (e.g. can retreive data(GET) or save data(PUT)). To learn more about routing and much more about ASP.NET MVC I would highly reccomend reading the book Pro ASP.NET MVC Framework by Steven Sanderson.

Entity Framework

To manage data in my application I'll use entity framework 5.0. EF provides you with three ways to define the model of your entities:

The Database First - begins with an existing database and reverse-engineer into a conceptual model.
The Model First - begins with an empty diagram - use the visual designer to design an EDM, then generate database schema from that model.
The Code First - begins with classes that describe your conceptual model.
In this example I'll use the Database First method. I will reverse-engineer only one table from my Tax database - Person table (again, I don't want here to build the whole Tax application but just to demonstrate how I would build a web app.) As mentioned above, the source code is on the GitHub and there you can find the SQL script that would generate and populate the database for you (in the script and in the source code on the GitHub I call the database TaxBlog, while here it is called Tax. It was changed after I wrote this post so I could continue working on my Tax app and have another database side by side). So if you want to follow and build the application while reading this blog, then make sure you build the database before you continue (see the Readme file on the GitHub).
Creating Model for Tax application (only Person)
  • Select Add and then New Item from the menu.


  • Select ADO.NET Entity Data Model from the filtered list of item templates. Change the name of the model to Tax.edmx and click Add

  • In the Choose Model Contents window, select Generate from database and then click the Next button.

  • On the Choose Your Data Connection page, select Tax database in the data connection drop down and click Next.



  • Then save entity connection settings in the Web.config and click Next.

  •  Then choose only table Person from the database.

And as a result we get the entity Person which represents the table from the Tax database.
To be honest we could use here DTOs (see the article that Antony Sneed wrote a long time ago) which might happen in some of the next blog posts but for now we'll be using classic enitites.

 Breeze.NET API

Breeze is made by the company called IdeaBlade and it is basically, a JavaScript data management library. It helps you manage data in rich client application. Breeze has a two parts of the setup: server and client. First we'll talk about the server part. There are a lot of reasons why I really like and choose Breeze but one that helps me decide is that Breeze ships with out-of-the-box support for the ASP.NET Web API and Entity Framework. As my example uses ASP.NET Web API controller (which will be covered further in the post) to handle the HTTP requests from the client and it uses the Entity Framework to model and access a SQL database, the Breeze offers me a wrapper component (called EFContextProvider) around the application's DbContext. It takes care of a lot of routine plumbing. I'll use out-of-the-box EFContextProvider but in real life you would probably customize it (e.g. intercept save requests and validate them, etc...). As we really appreciate a separation of concerns and loosely coupled layers:  we always try to reference interfaces so that the concrete implementation can be supplied at runtime. In that light, I will build repository pattern which allows me to easily replace EF with some other ORM (e.g. NHibernate,etc...) But before that I'll add Breeze for ASP.NET Web API using NuGet.


Now I'll build the repository interface:


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace TaxAppBlog.Models.Contracts
{
    public interface IBreezePersonRepository
    {
        IQueryable People { get; }
        string Metadata();
    }
}
Using IQueryable I am taking advantage of oData. Now I can use OData syntax of paging and querying people which I'll present you later in the post. Metadata is needed for the Breeze setup. "Breeze needs this metadata to communicate with the persistence service during query and save, to create new entities on the client, and to navigate among entities in cache. Because Breeze has metadata, it can generate your JavaScript model “classes” on the fly."
Now we'll be adding a new class BreezePersonRepository which will implement the interface IBreezePersonRepository.
Here we'll be using a Breeze EFContextProvider to query on EF or to get breeze metadata.

And finally BreezePersonRepository looks like this:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using Breeze.WebApi;
using TaxAppBlog.Models.Contracts;


namespace TaxAppBlog.Models.Implementations
{
    public class BreezePersonRepository : IBreezePersonRepository
    {
        readonly EFContextProvider _contextProvider =
            new EFContextProvider();
        public IQueryable People
        {
            get { return _contextProvider.Context.People; }
        }

        public string Metadata()
        {
            return _contextProvider.Metadata();
        }
    }
}
Now when the Breeze is set on the server, we are ready to build our WEB API. But before we do that we'll set the Autofac as our DI container.

Autofac - IoC container

Even though in my small example I wouldn't need to use any of IoC containers I did it to show that it's not so complicated (there is a lot of fear around about the complexity of the setup of the Ioc containers). I strongly advise everybody to use it when they build their application. At my work we are mostly using Unity but here I'll set another one which is called Autofac. I chose Autofac as it had correct benchmark results (benchmarks from some time ago IoC Container Benchmark - Performance comparison; IoC Container Benchmark ReRevisted - Ninject updated, Autofac added ) and it has ASP.NET MVC 4 Integration package as well as ASP.NET WEB Api Integration package. So to start adding the Autofac we'll call in help...who else but NuGet :) We'll be adding Autofac and its two integrations (ASP.NET MVC 4 and WEB Api)

To configure Autofac we'll add a new class and give it a name AutofacConfig:



In this class we'll register all MVC controllers then API controllers. We'll also set their lifetime scope: InstancePerApiRequest is part of the Web API integration, and InstancePerHttpRequest is part of the MVC integration. They both apply the same tag to the lifetime scope but it was done this way because you might have services that are dependencies of both Web API and MVC controllers. Then we register our container for MVC controllers and API controllers.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Http;
using System.Web.Mvc;
using Autofac;
using Autofac.Integration.Mvc;
using Autofac.Integration.WebApi;
using TaxAppBlog.Models.Implementations;

namespace TaxAppBlog.App_Start
{
    public class AutofacConfig
    {
        public static void Register(HttpConfiguration config)
        {
            var builder = new ContainerBuilder();
            builder.RegisterControllers(typeof(WebApiApplication).Assembly);
            builder.RegisterApiControllers(typeof(WebApiApplication).Assembly);
            builder.RegisterType().AsImplementedInterfaces().InstancePerApiRequest().InstancePerHttpRequest();
            var container = builder.Build();
            DependencyResolver.SetResolver(new AutofacDependencyResolver(container));
            GlobalConfiguration.Configuration.DependencyResolver = new AutofacWebApiDependencyResolver(container);
        }
    }
}
Now we need to call this class at the start of the application so we call it from Global.asax
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Http;
using System.Web.Mvc;
using System.Web.Optimization;
using System.Web.Routing;
using TaxAppBlog.App_Start;

namespace TaxAppBlog
{
    // Note: For instructions on enabling IIS6 or IIS7 classic mode, 
    // visit http://go.microsoft.com/?LinkId=9394801

    public class WebApiApplication : System.Web.HttpApplication
    {
        protected void Application_Start()
        {
            AreaRegistration.RegisterAllAreas();

            WebApiConfig.Register(GlobalConfiguration.Configuration);
            AutofacConfig.Register(GlobalConfiguration.Configuration);
            FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
            RouteConfig.RegisterRoutes(RouteTable.Routes);
            BundleConfig.RegisterBundles(BundleTable.Bundles);
        }
    }
}
So kids, that wasn't difficult :). Start using DI containers in your future projects if you haven't already done so. Now for the last element of server side setup we'll build our WEB Api service.

WEB Api

We'll add a new ApiController called BreezePeopleController (probably unfortunate name - should have omitted Breeze from the name).

Now our controller will look very simple
using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Net.Http;
using System.Web.Http;
using Breeze.WebApi;
using TaxAppBlog.Models;
using TaxAppBlog.Models.Contracts;

namespace TaxAppBlog.Controllers
{
    [BreezeController]
    public class BreezePeopleController : ApiController
    {
        IBreezePersonRepository repository;
        public BreezePeopleController(IBreezePersonRepository repository)
        {
            this.repository = repository;
        }

        public IQueryable GetPeople()
        {
            return repository.People;
        }

        // ~/api/BreezePeople/Metadata 
        [HttpGet]
        public string Metadata()
        {
            return repository.Metadata();
        }
    }
}
You noticed that our controller is decorated with the attribute BreezeController. Now why did we do that? "A Breeze server (read Web API controller) and a Breeze client (read BreezeJS) have a shared understanding about the nature and format of HTTP requests, responses and payloads. The Web API pipeline has to be configured to conform to that "understanding". Because your Breeze Web API Controller may cohabitate with other, non-Breeze controllers, Breeze shouldn't impose its configuration requirements on them. Therefore, we should configure the Web API pipeline on a controller basis ... and that's what this BreezeController attribute does.
When the Web API routes a request to the BreezePeopleController, it creates a new instance of that controller type and then calls the BreezeController attribute to configure the Web API pipeline for this controller instance only.
Always decorate your Breeze controller with the BreezeController attribute."
We used Constructor Injection to inject references of our IBreezePersonRepository implementation (here one can see how this is really decoupled.) Before we go further and setup the client we'll test the server side setup. In short, we'll run the application and request the URL of the method GetPeople.
As a result we'll get the JSON formatted results. The question to open it pops up...
  
 
...and after we open it in notepad we see our data in JSON format.
Here I am going to show how you can inspect the results in more elegant way by using Fiddler. First you enter the url in the composer and execute it.
Then go to the Inspector tab and verify your results.
As the last thing before we move on to the client setup, I'll show you how to query/sort data using OData syntax (which I promised above while setting People property as IQueryable). Again, open the Composer tab in the Fiddler and change the URL into something like this: http://localhost:17612/api/breezePeople/getPeople?$top=1&$orderby=FamilyName (where 17612 is only my asp.net development web server port - if you run your project in visual studio chances are you are going to get a different port number). Take note that we specified that we want the top 1 record and to be ordered by FamilyName.


After executing composer, go and verify your results (Inspector tab) - we actually retreived only one record and sorted by FamilyName.


 Finally, the server side is up and running so we can move to the client side.

CLIENT

BreezeJS

For client side setup we'll start with BreezeJS. In general, what we'll do is download script libraries by using NuGet then we'll "bundle" them and we'll also add reference in the _Layout.cshtml so they can be available in all views (only those that are using _Layouts.cshtml as master page of course). Breeze scripts are already downloaded and added to the project with the package "Breeze for ASP.NET Web Api projects" that we got during the Breeze setup in the server section (see above "Breeze.NET API").
On the client side we work with Breeze Entity manager class. The Entity Manager is a core class in Breeze. When the client app asks for data it calls a method on an instance of an Entity Manager. Entity Manager is a gateway to our persistance model. It reads the data model supplied by our services metadata and produces a Java Script "entity" object which we'll use further for our data binding. The brilliant thing is that it doesn't require you to do anything on the client side in terms of manually defining entity classes or write any mapper. The Entity Manager acts as its own data context on the client side which means when you create multiple instances of the Entity Manager then they are completely independent, each having its own cache. What they share is that they talk to the same service and they share the same Metadata store. I prefer to have a shared entity manager. The way that we can achieve this is if we encapsulate the application manager within the "dataservice" module. All the other modules reference this dataservice module and ask it for data.
(function (root) {
    var breeze = root.breeze;
    var app = root.app = root.app || {};
    // show logger initially
    Logger.show();    
    log("Window is loaded.");

    var serviceName = 'api/BreezePeople';
    var manager = new breeze.EntityManager(serviceName);

    // add members to the dataservice
    var dataservice = {
        getAllPersons: getAllPersons
    };

    // extend the app with this dataservice
    app.dataservice = dataservice;

    // gets all Persons asynchronously
    // returning a promise you can wait for     
    function getAllPersons(peopleArray) {
        log("querying for all persons")
        var query = new breeze.EntityQuery()
                .from("GetPeople");

        return manager
           .executeQuery(query)
           .then(function (data) {
               processResults(data, peopleArray);
           })
           .fail(queryFailed);
    }

    // clears observable array and loads the person results 
    function processResults(data, peopleArray) {
        log("Clears observable array and loads the person results.");
        peopleArray.removeAll();
        var persons = data.results;
        persons.forEach(function (person) {
            log("adding " + person.FirstName._latestValue + " " + person.FamilyName._latestValue);
            peopleArray.push(person);
        });
    }

    function queryFailed(error) {
        log("Query failed: " + error.message);
    }

}(window));

For debugging purposes I've used a logger class which prints debugging messages on a separate console window at the bottom of the web browser (which is very handy). The logger can be found here.  So what we did here is create an entity manager and use it to execute the query (.executeQuery(query)) which is an asynchronous method and returns a promise to call back either the processResults method if the query succeeds or the queryFailed method if the query execution fails with an exception. The dataservice is added to the namespace app so it can be called from different viewmodels. Now we finally come to UI data binding with Knockout.

KnockoutJS

First we'll download Knockout using NuGet:

...then we'll "bundle" them:

As a big fan of the KnockoutJS I'll say just a couple of words about what KO (short for Knockout) is, what it is not and why and how to use it. KnockoutJS is a JavaScript library that helps you to create rich and responsive interfaces with a clean underlaying data model by using a MVVM approach. Basically, when you make calls via ajax and update your UI elements, things can get a little messy. Knockout can make it simpler and more uniform. It is a self contained JavaScript library (14Kb - gzip), supports all mainstrem browsers and what is really nice - no dependencies. It is important to understand that it is not a replacement for JQuery and it is not a Prototype for JavaScript. There are three core features of KnockoutJS. The first is Observables and dependency tracking - it updates your UI automatically. When you change a viewmodel it updates UI elements also. How can Knockout  know that a part of your viewmodel changed, well the answer is: it needed to query model properites as observables because they are special JavaScript objects that can notify the subscribers about changes and then it can automatically detect dependencies. The second feature is Declarative Bindings - this is a simpe and obvious way to connect a part of your UI to your data model. You can now construct complex dynamic UI easily and arbitrarily using these databinding contracts. The third important feature is Templating - Template binding populates the DOM element with the results of rendering template. This means that teamplates are a simple and convinient way to build UI structures possibly with repeating or nested blocks as a function of your viewmodel data. To learn more on KnockoutJS please go here. One of the reasons that Knockout was created was enabling MVVM style development for websites/web applications. So I'll say a couple of words about it also. MVVM is a design pattern for building user interfaces. It describes how you can keep a potentially sophisticated UI simple by splitting it in three parts (separation of concerns). The first part is Model. The model is simply your application store data (in our application we use breeze/web api to read and write model data) The second part is ViewModel - Entity(field) structure of your data. This is a pure code representation of the data and operations in the UI. When using KnockoutJS your ViewModel is pure JavaScript that holds no knowledge of HTML. Keeping the ViewModel abstract this way let us stay simple so we can easily manage more sophisticated behaviour without getting lost :) And finally the last part is View - UI representation of the current state of ViewModel and interactions within it. So when using KnockoutJS your view is simply in your HTML document with declarative binding that links to the ViewModel (alternatively you can use templates that generate HTML using data from your ViewModel). The beauty of solid MVVM library such as Knockout is that you can focus on develping business logic instead of writing code to attach/detach event handler an manually update UI elements whenever data values change. Our ViewModel exposes people as observableArray and hide as observable bool to be bound on the view.

(function (root) {
    var app = root.app;
    var dataservice = app.dataservice;

    var vm = {
        people: ko.observableArray([]),
        hide: ko.observable(true)
    };

    getAllPersons()
        // reveal view when query succeeds
        .then(function () { vm.hide(false); });

    app.peopleViewModel = vm;

    function getAllPersons() {
        return dataservice.getAllPersons(vm.people);
    }

}(window));

To get data we used our breeze dataservice. We also added our viewModel (peopleViewModel) to the app namespace so it can be accessed and data bound in the Main.js
(function (root) {
    var app = root.app;

    log("Breeze Devices is booting");

    ko.applyBindings(app.peopleViewModel);

}(window));

KoGrid

And finally in the view I will use KoGrid. I haven't explored KoGrid much, but as far as I have played with it, it is extremely simple and friendly to make work with KnockoutJS. As for all other libraries we'll first download it and add it to the project using NuGet.
Now when all libraries are downloaded and added to the project I will show you what Bundle.Config looks like:
using System.Web;
using System.Web.Optimization;

namespace TaxAppBlog
{
    public class BundleConfig
    {
        // For more information on Bundling, visit http://go.microsoft.com/fwlink/?LinkId=254725
        public static void RegisterBundles(BundleCollection bundles)
        {
            bundles.Add(new ScriptBundle("~/bundles/jquery").Include(
                        "~/Scripts/jquery-{version}.js"));

            bundles.Add(new ScriptBundle("~/bundles/jqueryui").Include(
                        "~/Scripts/jquery-ui-{version}.js"));

            bundles.Add(new ScriptBundle("~/bundles/jqueryval").Include(
                        "~/Scripts/jquery.unobtrusive*",
                        "~/Scripts/jquery.validate*"));

            bundles.Add(new ScriptBundle("~/bundles/knockout").Include(
                       "~/Scripts/knockout-{version}.js",
                       "~/Scripts/knockout-{version}.debug.js"));

            bundles.Add(new ScriptBundle("~/bundles/koGrid").Include(
                        "~/Scripts/koGrid.min.js",
                        "~/Scripts/koGrid.debug.js"));

            bundles.Add(new ScriptBundle("~/bundles/q").Include(
                        "~/Scripts/q.js",
                        "~/Scripts/q.min.js"));

            bundles.Add(new ScriptBundle("~/bundles/breeze").Include(
                        "~/Scripts/breeze.js",
                        "~/Scripts/breeze.debug.js",
                        "~/Scriptsbreeze.intellisense.js"));

            
            bundles.Add(new ScriptBundle("~/bundles/logger").Include(
                        "~/Scripts/App/Logger.js"));

            bundles.Add(new ScriptBundle("~/bundles/app").Include(
                        "~/Scripts/App/TaxDataService.js",
                        "~/Scripts/App/TaxPayerViewModel.js",
                        "~/Scripts/App/main.js"));
            // Use the development version of Modernizr to develop with and learn from. Then, when you're
            // ready for production, use the build tool at http://modernizr.com to pick only the tests you need.
            bundles.Add(new ScriptBundle("~/bundles/modernizr").Include(
                        "~/Scripts/modernizr-*"));

            bundles.Add(new StyleBundle("~/Content/css").Include(
                        "~/Content/site.css", 
                        "~/Content/KoGrid.css",
                        "~/Content/ie.css",
                        "~/Content/print.css",
                        "~/Content/screen.css"
                        ));

            bundles.Add(new StyleBundle("~/Content/themes/base/css").Include(
                        "~/Content/themes/base/jquery.ui.core.css",
                        "~/Content/themes/base/jquery.ui.resizable.css",
                        "~/Content/themes/base/jquery.ui.selectable.css",
                        "~/Content/themes/base/jquery.ui.accordion.css",
                        "~/Content/themes/base/jquery.ui.autocomplete.css",
                        "~/Content/themes/base/jquery.ui.button.css",
                        "~/Content/themes/base/jquery.ui.dialog.css",
                        "~/Content/themes/base/jquery.ui.slider.css",
                        "~/Content/themes/base/jquery.ui.tabs.css",
                        "~/Content/themes/base/jquery.ui.datepicker.css",
                        "~/Content/themes/base/jquery.ui.progressbar.css",
                        "~/Content/themes/base/jquery.ui.theme.css"));
        }
    }
}

...and also what our master page looks like containg all necessary references:
 <!DOCTYPE html>
  
 <html>  
 <head>  
   <meta charset="utf-8" />  
   <meta name="viewport" content="width=device-width" />  
   <title>@ViewBag.Title</title>
   @Styles.Render("~/Content/css")  
   @Scripts.Render("~/bundles/modernizr")  
   @Scripts.Render("~/bundles/logger")  
 </head>  
 <body>  
   <nav class="container">  
     <div id="header" >  
       <div id="logo">  
         <h1>Tax Application (sample for blogging purposes :))</h1> 
       </div>
     </div>  
     <nav>  
       <ul id="menu">
         <li>@Html.ActionLink("Home", "Index", "TaxPayer")</li>
         <li>@Html.ActionLink("Tax Payer", "Index", "TaxPayer")</li>
       </ul>
     </nav>
     <div id="main">
       @RenderBody()
     </div>
   </div>
   @Scripts.Render("~/bundles/jquery")
   @Scripts.Render("~/bundles/knockout")
   @Scripts.Render("~/bundles/koGrid")  
   @Scripts.Render("~/bundles/q")
   @Scripts.Render("~/bundles/breeze")
   @Scripts.Render("~/bundles/app")
   @RenderSection("scripts", required: false")  
 </body>  
 </html>  
Notice that we are referencing JavaScript files in the bottom of the page. Why? Well first because the entire visual markup is processed before the script references are and thus will be displayed on the screen while the referenced JavaScript libraries are downloading and being processed into browser memory; and second some of this libraries works with DOM (e.g. Knockout) and in order to do so the browser needs to have created and rendered portions of the DOM before the Knockout executes.
Now finally in the TaxPayer view we bind our grid to the "people" propery of our viewModel but also we use the property "hide" to first show loading gif(ajax-loader.gif) while data is loading and then hide the gif but show the grid:
@{  
   ViewBag.Title = "Index";  
 }  
 <!DOCTYPE html>  
 <html>  
 <body>  
   <div id="body">  
     <div id="imageWrapper" align="center">  
       <img id="loader" src="images/ajax-loader.gif" data-bind="visible: hide()" />  
     </div>  
     <div id="gridWrapper" data-bind="visible: !hide()">  
       <div id="sandBox" style="height: 200px;" data-bind="koGrid: { data: people,  
          columnDefs: [{ field: 'FirstName', width: 100 },  
                    { field: 'FamilyName', width: 110 }, 
                   { field: 'BirthDate', width: 100 },  
                   { field: 'Profession', width: 100 },  
                   { field: 'Telephone', width: 100 },  
                   { field: 'Address', width: 150 },  
                   { field: 'City', width: 100 },  
                   { field: 'Country', width: 100 },  
                   { field: 'Email', width: 150},  
                   { field: 'Twitter', width: 110 } 
         ],  
              autogenerateColumns: false,  
              isMultiSelect: true,
              enablePaging: false }">  
       </div>  
     </div>  
   </div>  
 </body>  
 </html>  

Here you can see how easy and elegantly we bind our kogrid. Now when we run the project we'll first get the loading gif:


...until the data is loaded when the grid is shown:


So here we have a taxpayer screen up and running. Now we can think of adding more features (e.g. add/update/delete) and e.g. setup all maintenace screens uniformly like this one.
Thanks for reading this post and letting me know if you like it or not, what would you change and how.

Hello world :)

Hello,
Welcome to my latest blog! This is my New Year's resolution, even though I don't have much time for it (full time job + wife and three kids + a couple of other occupations, including learning the Luxembourgish language and brushing up on my French and English...).
Here, I'll be writing some C#, some Java script (especially web UI development), some Azzure and at work lately I am doing a lot of SQL and also Sharepoint development (working with some really knowledgeable colleagues) so I'll be posting some interesting things.
Before of any of my posts I'll remind you that my English is not perfect (far from it) with the following statement:
As English is not my mother tongue and before I really start writing anything, I have to apologize for any language mistakes I make.