JavascriptMVC

The last week I finally had time to put my hands on http://www.javascriptmvc.com/, I heard about that framework sometime ago but I didn't toke time to play with it, I was a little bit tired about my SaaS ASP.Net MVC framework  that I am working on, so I decided to take a look to that framework.

When I first saw the Javascript MVC video tutorial I was exited about how easy you can create a simple application following the MVC pattern with javascript so I decided to create a very simple application (TODO list) with a WCF REST service connected to it, this is the final version of the app that I created:

After being working with Asp.Net MVC for a while I didn't have any problem following the javascript code and I found the approach very interesting, as the framework is designed to work together with a REST service by default the app runs pretty fast, because small chunks of data are sent and received to/from the service, I know that you can do the same with normal ASP.Net MVC but that is something that usually you do don't do in your firsts projects because usually you are following a simple tutorial that works with normal posts and gets(ajax or no ajax), the advantage of developing the app with Javascript mvc is that you are forced to write your app that way(ajax, json, REST, etc.), also, as the framework helps you writing unit and functional tests so your app will be more robust and you will learn some tricks that you can apply to other applications, of course I have only created a very simple app and only it will be after I create something more complicated that I will know the limitations and trade offs of using that framework.

For the moment you can download the sample app that I wrote here:

I changed the framework's source code a little bit to make the testing faster, now the application detects when its being executed in the context of a unit or functional test so all the ajax requests are emulated and the app works only with data in memory, also I allowed the user to manually set the app to run in test mode so you don’t be messing with real data when you are developing, testing and debugging your app and tests.

These are some tricks and gotchas that I found when I was developing the wcf REST service:

• You cannot make ajax post/delete/put request to other domain, I knew this one but I wasted a couple of hours because I just forgot it, well, you can do it with some tricks but not naturally.
• If you want your service to return real json and not a string that represents a json object you should not return a string in your web method, let me elaborate, almost all of the tutorials and comments on internet just said that you have to add the following parameters to your WebInvoke attribute: BodyStyle = WebMessageBodyStyle.Bare, ResponseFormat = WebMessageFormat.Json  but that is not enough others said that just setting the correct ContentType will do the trick, but that does not work either, and that’s because no matter that you are returning a json object (as string) the response will be wrapped so your return value will be wrapped as if it was a normal string, this is not actually a real problem since you can then convert that string into json object(s) in js with a simple instruction like: jQuery.parseJSON(StringData) but as you can imagine, if your data is very large the conversion will take a while and the browser will blocked by this conversion, also, why convert the data if we can just send it correctly?, to make it work, you service has to return a Stream and you should write your json serialized object into that Stream.
• Serialize your object with the DataContractJsonSerializer instead of the JavaScriptSerializer, this way you will have complete control on how your object is serialized.

This is the structure (not detailed) of the sample solution:

• The root folder contains the wcf service and other classes that I use in the service's code.
• The RestServiceCode contains code required by the Rest service.(this note was added by captain obvious)
•  documentjs, funcunit,jquery and steal folders are javascript mvc stuff.
• todo folder, this is where the javascript mvc app resides, I suggest that you take a look to the video tutorial so you are familiarized with the structure of an javascript mvc app.
• The DBScripts folder that contains one big script to create the db and populate a few tasks.

Running the sample code:

• Create a database called ToDoDB (use that name so you don’t have to change the script).
• Run the script included in the source code.
• Modify the web.config and the app.config (tests project) so it points to your new DB.
• Run the app, if you don’t see a thing, check that your browser its pointing to this url:http://localhost:19978/todo/todo.html  (or the port that is configured in your machine)
• If you want to run the app in test mode just add the query string test=true, so the url will be something like: http://localhost:19978/todo/todo.html?test=true 
• To run the unit and functional tests follow the instructions on the video tutorial.
• That’s all.

Please notice that the app does not follow all the best practices and I just wrote two normal MS tests to test the service, the intention of the sample code is not to teach best practices but to show a javascriptmvc working app .

Comments and questions are welcome.

Data Access with Cheetah Framework.

  As I mentioned in my previous post, I am working on a Framework(Cheetah Framework) that will help developers writing SaaS applications with asp.net MVC, in this post I will be talking about how the Cheetah Framework help developers with the data access for SaaS applications.

First of all, usually there are three main ways that the data is stored on the server:

1. Isolated Schema, isolated database.
2. Isolated Schema, shared database.
3. Shares schema, shared database.

For more information about advantages and disadvantages about each model you can go here

Cheetah Framework uses the third option, i.e. shared schema, shared database, to make it work, Cheetah Framework needs you to follow some simple rules when creating your database, oh and by the way, Cheetah Framework supports SQL server and SQL Azure, once you have your database defined, you need to configure just one connection string and update one single file(no single line of code involved) and Cheetah Framework takes control from there, just compile your project and you will have access to functionality that was generated for you.

Cheetah Framework will automatically filter the data based on the active tenant so developers will work with the data as if they were developing a single tenant application, also Cheetah Framework has built in support that allows the tenant to extend any table in their database, so, for instance, developers can define a base table "Products" with a fixed set of fields and each tenant will be able to extend the "Products" table to fit their needs, in terms of code, developers can access those extended fields directly as if they were part of the "Products" table, something like:

NewProduct.MyCustomField = "test"

This feature is also useful when creating verticals, lets said that you are creating a  Time Track SaaS application, you can define a vanilla app and then define extended fields for specific verticals, like Time Track for Developers, Time Track for Doctors, Time Track for teachers, and so on, also each vertical's tenant will be able to add their own custom fields.

The following is an example with the current version of the Cheetah Framework that was added to a vanilla MVC application:

This is the aspnet_Users table: 

As you can see the field "FirstName" is not part of this table.

This is the basic code that you will need in the controller:

And this is a simple example of  the View :

 


As you can see, you use the extended field "FirstName" as it was part of the original object, any extended fields can be accessed that way.


Well, thats all for now, in the next post I will continue talking about how the data is accessed and other things that Cheetah Framework does for you.