Working with Sencha EXTJS and WCF Service (Fetch Data)

JavaScript frameworks are the next future in application development. They provide a very effective, fast and modern way to develop and maintain the web application which gives it a desktop application look and feel.

Sencha EXTJS is one of the many available such frameworks.

I'm into MS technologies mainly ASP.NET.
Following is a basic example of how to connect to WCF services using EXTJS into ASP.NET application.

On WCF service project -

Create a WCF service which returns a list of users to the consumer (If you are looking for the EXTJS with WCF solution then I think I dont need to tel how to create a WCF service :))

The most important thing to do at WCF side -

Add following code in the global.asax of WCF solution -

  protected void Application_BeginRequest(object sender, EventArgs e)
        {
            HttpContext.Current.Response.AddHeader("Access-Control-Allow-Origin", "*");
            if (HttpContext.Current.Request.HttpMethod == "OPTIONS")
            {
                HttpContext.Current.Response.AddHeader("Cache-Control", "no-cache");
                HttpContext.Current.Response.AddHeader("Access-Control-Allow-Methods", "GET, POST");
                HttpContext.Current.Response.AddHeader("Access-Control-Allow-Headers", "Content-Type, Accept, x-requested-with");
                HttpContext.Current.Response.AddHeader("Access-Control-Max-Age", "1728000");
                HttpContext.Current.Response.End();
            }
        }

This code is required to handle request with uri having additional params.

The Store   
Ext.define('My.store.Users', {
    extend: 'Ext.data.Store',
    model: 'AM.model.User',
    autoLoad: true,
    proxy: {
        type: 'ajax',       
            url: 'http://localhost/EXTJSService/RestService.svc/getUsers',
        reader: {
            type: 'json',
            root: 'GetUsers'
        }
    }
});

Here url is the path of your WCF service, in this example its hosted on the same machine, localhost.

root is the root element if the resultant JSON data (in most of the examples you will find it "d:")

View -
Ext.define('My.view.user.List', {
    extend: 'Ext.grid.Panel',
    alias: 'widget.userlist',
    title: 'All Users',
    store: 'Users',
    initComponent: function () {
        this.columns = [
            { header: 'ID', dataIndex: 'ID', flex: 1 },
            { header: 'Name', dataIndex: 'FirstName', flex: 1 },
            { header: 'Email', dataIndex: 'Email', flex: 1 }
        ];
        this.callParent(arguments);
    }
});

Important things to note is the mapping of fields in the grid, these should map to the field names in the JSON data.

Hope you find it useful.
Enjoy....

Difference between Passimistic and Optimistic locking

Optimistic Locking is a strategy where you read a record, take note of a version number and check that the version hasn't changed before you write the record back.

When you write the record back you filter the update on the version to make sure it's atomic. (i.e. hasn't been updated between when you check the version and write the record to the disk) and update the version in one hit.
If the record is dirty (i.e. different version to yours) you abort the transaction and the user can re-start it.

This strategy is most applicable to high-volume systems and three-tier architectures where you do not necessarily maintain a connection to the database for your session. In this situation the client cannot actually maintain database locks as the connections are taken from a pool and you may not be using the same connection from one access to the next.


Pessimistic Locking is when you lock the record for your exclusive use until you have finished with it. It has much better integrity than optimistic locking but requires you to be careful with your application design to avoid Deadlocks.

To use pessimistic locking you need either a direct connection to the database (as would typically be the case in a two tier client server application) or an externally available transaction ID that can be used independently of the connection.

In the latter case you open the transaction with the TxID and then reconnect using that ID. The DBMS maintains the locks and allows you to pick the session back up through the TxID.