Here’s what Entity Framework (EF) has to offer:

• Using EF with the Model First approach, you design a schema of the model you want to implement, and EF generates a database and the code to implement it. Now, that’s what I call saving time! Using this approach, you can get going really really quick.
• If you already have the code for your model, then EF can generate the database to store this model as well as the rest of the code handling persistance to this database, using the Code First approach.
• In case you already have the database, EF can generate the code using the Database First approach.
• EF uses Plain .Net objects (POCOs) with navigational properties to implement your model. Very easy stuff. The way EF lets you interact with the data once it’s retrieved from the DB is piece of cake (not the fact of data retrieval itself, that can get tricky).
• Automatic code generation with T4 templates. Once you have EF set up in your project, there’s a bunch of templates to generate a lot of code for you. That doesn’t mean you must use it, but it’s there for your convenience, in case you think some templates can help you. Me myself I use some of the T4 templates, but not all of them. There’s some things I actually prefer doing manually.
• Self-tracking entities will greatly simplify the process of implementing an over-the-wire scenario, in which you have different layers spanning across different systems and you have to serialize and de-serialize your entities. EF makes this really easy.
• Local caching, to speed up your data access.
• Lazy loading, which can improve overall application performance.
• Support for LINQ (both coming from Microsoft, you would expect this, right?).
• Convention over configuration. The hottest trend in software development. You wouldn’t think EF would miss it, would you? When starting up a new project with EF, the only thing you need to configure are the database server and its name. Nothing else. All other things are taken care of for you. Of course, if you want more control over what EF is doing, you can tweak it to meet your criteria. But that isn’t something you have do right at the beginning. This way, you can be productive much faster.
• Support for the major databases: MS SQL Server (of course), Oracle, MySQL, PostgreSQL, etc…

And last but not least:

• Coming from a big player in the industry like Microsoft, Entity Framework has great resources and a great community behind it. If you ever have a problem with EF, or want to tweak its behavior, chances are you’ll be finding what you need really fast. If you’re a seasoned developer, you’ll find this is one of the most important features of EF.

If you haven’t tried it out yet, don’t wait any longer and see for yourself what I’m talking about!

Related posts:

1. Persistance layer: object-relational mapping tools
2. Which database to use for a personal project?
3. Sluggish database view? Materialize it!
4. ASP.NET 4.5 and Visual Studio 11

• ASP.NET Core Runtime and Framework
  • Asynchronously Reading and Writing HTTP Requests and Responses.
  • Improvements to HttpRequest handling
  • Asynchronously flushing a response
  • Support for await and Task-Based Asynchronous Modules and Handlers
  • Asynchronous HTTP modules
  • Asynchronous HTTP handlers
  • New ASP.NET Request Validation Features
  • Deferred (”lazy”) request validation
  • Support for unvalidated requests
  • Anti-XSS Library
  • Support for WebSockets Protocol
  • Bundling and Minification
  • Performance Improvements for Web Hosting
    • Key Performance Factors
    • Requirements for New Performance Features
    • Sharing Common Assemblies
    • Using multi-Core JIT compilation for faster startup
    • Tuning garbage collection to optimize for memory
    • Prefetching for web applications
• ASP.NET Web Forms
  • Strongly Typed Data Controls
  • Model Binding
    • Selecting data
    • Value providers
    • Filtering by values from a control
  • HTML Encoded Data-Binding Expressions
  • Unobtrusive Validation
  • HTML5 Updates
• ASP.NET MVC 4
• ASP.NET Web Pages 2
  • New and Updated Site Templates
  • Improved Input Validation
  • Resource Management
  • Enhanced Membership and Authentication
  • Side-by-side Execution
  • Mobile Device Rendering
  • The Maps Helper
• Visual Web Developer 11 Developer Preview.
  • HTML Editor
    • Smart Tasks
    • WAI-ARIA support
    • New HTML5 snippets
    • Extract to user control
    • IntelliSense for code nuggets in attributes
    • Automatic renaming of matching tag when you rename an opening or closing tag
    • Event handler generation
    • Smart indent
    • Auto-reduce statement completion
  • JavaScript Editor
    • Code outlining
    • Brace matching
    • Go to Definition
    • ECMAScript5 support
    • DOM IntelliSense
    • VSDOC signature overloads
    • Implicit references
  • CSS Editor
    • Auto-reduce statement completion
    • Hierarchical indentation
    • CSS hacks support
    • Vendor specific schemas (-moz-, -webkit)
    • Commenting and uncommenting support
    • Color picker
    • Snippets
    • Custom regions
  • Page Inspector
  • Publishing
    • Publish profiles
    • ASP.NET precompilation and merge
  • IIS Express

These are developer previews, which mean that they should be used for testing purposes only, and never in production environments – not yet, at least.

In case you’re interested, Microsoft’s central hub for ASP.NET’s next version articles is ASP.NET vNext section.

Via Microsoft’s ASP.NET web site.

Related posts:

1. Different ways to use AJAX in ASP.NET
2. PHP or ASP.NET?

If we’re using objects in our application and we want to save them, we’ll probably use some data base system. We’ll most likely establish a connection to the data base, create a SQL sentence with the values of the object (or call some kind of stored procedure), and save them to some table. Easy enough, right? Well, this may seem trivial for a small object with 4 or 5 properties. Just consider an object not so small, with 40 or 50 properties. But… what happens with associations? And… what if the object itself contains some other objects? We’ll store them in the data base as well? All of them or just some? What will we do with foreign keys? We can see that, as the application gets more complex, this translation is not so trivial anymore… As a matter of fact, storing objects in the database can become a very usual source of headaches. There are some studies which state that up to 35% of code is dedicated to the role of translating data between the application and the data warehouse.

And this is where Object-Relational Mapping tools come into play. ORM tools applied to databases transform a DB register to a code object and vice-versa, allowing us to abstract away from writing code to directly access the database. This will speed up development and will allow us to follow the mantra of focusing on business functionalities, not on application plumbing.

But, what exactly can an ORM tool helps us with? Well, they usually do some things like:

• Handle object persistance (to a database, for example). You won’t have to write code for this. And remember, less code means less bugs and less headaches.
• Access different databases. Most of these tools support communicating with different database providers (Oracle, MS SQL Server, MySql, Postgre, etc.).
• Cache. Many of these tools offer some way of caching objects in memory, resulting in much faster data access.
• Help with design. Some of these tools also provide some kind of wizard or graphical interface to aid in the design of the schema and/or database, which leads us to the following point:
• Create your database for you. If you have your data schema already modeled, some of these tools will not only handle how to get the data or how to write it. They can also create the database.

You’re already convinced to use an ORM for your project, right? Good. Now take a look at the most popular ORM tools available for .NET:

• Linq to SQL: not really a full-blown ORM, but it does help with data access.
• NHibernate: I would say NHibernate is one of the most mature ORM projects in .NET, and one of the most used as well.
• Entity Framework: Microsoft’s new kid on the block. Its first version didn’t receive very positive comments, but its latest release looks very good indeed.
• LLBLGen Pro: very mature project, although it’s not the simplest of all.
• DataObjects.Net: quite new, but very promising. It already has a lot of interesting features. Definetely worth taking a look at.

In the next post I’ll be covering Entity Framework a bit. Stay tuned!

Related posts:

1. Entity Framework
2. Some open source projects for .NET you should take a look at
3. Which database to use for a personal project?
4. Sluggish database view? Materialize it!
5. Software design patterns (II): creational patterns

• Task Parallel Library: this new library, included in the namespace System.Threading.Tasks.Parallel, has new elements to execute tasks in parallel automatically. It’s got, for example, a parallel For loop, and a parallel ForEach loop.
• Parallel LINQ Execution Engine: as you can guess, it’s a parallelized version of Linq to Objects. It’s the same thing, except that it will run in parallel whenever possible.
• Coordination Data Structures: it’s a set of primitives for sincronization and thread-safe collections. For example, we have thread-safe dictionaries, stacks and buffers, and special objects for thread sincronization, such as SpinWait or SpinLock.

Now, the good part about these parallel extensions is that it gets extremely easy to do parallel programming. Just by using these new features, your code will escalate to use as many parallel threads as possible. For example, in a machine with just one processor all your code will execute sequentially, just as always. But, in an 8-core-processor computer, your code will be broken down into 8 different threads, and they all will execute your code in parallel –assuming all 8 cores are available, of course. You can learn more this article from MSDN.

Related posts:

1. Persistance layer: object-relational mapping tools
2. ASP.NET 4.5 and Visual Studio 11
3. Entity Framework

TDD is a programming methodology that involves two other practices: test first development, and refactoring. First a set of unit tests is written and verified to fail. Then, code to make them pass must be written, and lastly this code is refactored. The aim of TDD is to achieve clean code that works. The main idea around this methodology is that requirements must be translated into automated tests: thus, when these tests pass, all requirements are guaranteed to have been accomplished. The application to be developed must be flexible enough to allow automated tests to be run. Each test should be small enough to exactly determine which piece of code is failing.

Test-driven development cycle

Once a set of requirements has been defined, a new cycle starts:

1. Choose a requirement: select a requirement you understand and about which you can write code both to test it and to implement it.
2. Write a test: the first code you must write is a test to determine whether the requirement is met, accessing the code through its interfaces. This step makes the programmer consider the problem from the client perspective.
3. Verify the test fails: if the test doesn’t fail it’s because this requirement is already implemented, or because the test is incorrect.
4. Write the implementation: Write the simplest code that will make the test pass. Follow the KISS philosophy (Keep It Simple, Stupid!).
5. Run the automated test: Verify whether the whole set of tests are passed.
6. Refactor: usually used to take out duplicate code. Each change should be made in small increments, and with each increment the tests should be re-run.
7. Update the requirements list: once the requirement is met mark it as done. Besides, add more requirements that may have been detected in this cycle or design requirements, like, for example, some functionality that has been decoupled from another one.

Having a repository of tests makes another good practice easier: frequent integration. Integrating our work frequently with the rest of the team allows us to check whether our code is compatible with the rest of the application, and makes it easier to detect bugs in an early phase. It is much easier and cheaper to fix bugs every few hours than facing enormous problems close to a release date.

Generation of tests for each functionality means that programmers can trust the code. This means that we can make big modifications deep in the core of the system that we would otherwise avoid, since we can be certain that, as long as all the tests pass, the code works as intended and the requirements are still met.

Another thing to keep in mind is that programmers must make the unit tests fail. Unit tests must be tested. The idea is to be sure that unit tests really work, and that they’re able to pick up an error whenever it happens.

Advantages

Programmers that use test-driven development from the beginning of a project find that they seldom have the necessity to use a debugger. In the few occasions that a bug is discovered, it is very easy to fix.

Despite of the high initial requirements of this methodology, TDD may provide a great added value to the software development process, producing higher-quality applications in less time. TDD not only offers a simple requirements validation: it can also lead the design of a program. By writing unit tests, a programmer must imagine how customers will be using the functionality, which may avoid some misinterpretations or bad implementations of a functionality.

Limitations

In order to follow the test-driven development methodology, tests must be automated. This may turn out to be rather complex in the following situations:

• Graphical User Interfaces, although there are some partial solutions proposed.
• Distributed Objects, even though Mock Objects may help.
• Data bases: writing tests that work with data bases is quite complex, since you need to put some known data before, and you have to verify that the contents of the database is the expected once the test is done. This makes these kinds of tests costly to develop.

Test-driven development is a programming methodology that should be in place in all organizations that develop software and consider themselves serious. Unfortunately, this is not the case. I hope things start to change in the near future!

Related posts:

1. Improving software quality: automatic testing
2. GUI Testing
3. Unit testing

• NHibernate: NHibernate is a mature, open source object-relational mapper for the .NET framework. It’s actively developed, fully featured and used in thousands of successful projects.
• NUnit: NUnit is a unit-testing framework for all .Net languages, initially ported from  JUnit. It is written entirely in C# and has been completely redesigned to take advantage of many .NET language features, for example custom attributes and other reflection related capabilities. NUnit brings xUnit to all .NET languages
• jQuery: jQuery is a fast and concise JavaScript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development. jQuery is designed to change the way that you write JavaScript.
• Rhino.Mocks: A dynamic mock object framework for the .Net platform. It’s purpose is to ease testing by allowing the developer to create mock implementations of custom objects and verify the interactions using unit testing.
• MVC Contrib: This is the contrib project for the ASP.NET MVC framework. This project adds additional functionality on top of the MVC Framework. These enhancements can increase your productivity using the MVC Framework. It is written in C#. Founded by Eric Hexter and Jeffrey Palermo.
• CruiseControl.NET: CruiseControl.NET is an Automated Continuous Integration server, implemented using the Microsoft .NET Framework.
• S#arp Architecture: Pronounced “Sharp Architecture,” this is a solid architectural foundation for rapidly building maintainable web applications leveraging the ASP.NET MVC framework with NHibernate. The primary advantage to be sought in using any architectural framework is to decrease the code one has to write while increasing the quality of the end product. A framework should enable developers to spend little time on infrastructure details while allowing them to focus their attentions on the domain and user experience.
• Spark View Engine: Spark is a view engine for Asp.Net Mvc and Castle Project MonoRail frameworks. The idea is to allow the html to dominate the flow and the code to fit seamlessly.
• TortoiseSVN: A Subversion client, implemented as a windows shell extension. TortoiseSVN is a really easy to use Revision control / version control / source control software for Windows. Since it’s not an integration for a specific IDE you can use it with whatever development tools you like.
• Castle Windsor: Castle Project offers two Inversion of Control Containers. The MicroKernel and the Windsor Container. Castle Windsor aggregates the MicroKernel  and exposes a powerful configuration support. It is suitable for common enterprise application needs. It is able to register facilities and components based on the configuration and adds support for interceptors.

Take a look at these projects. I’m sure you’ll be able to find some good use for them in your projects!

Via .NET Zone.

Related posts:

1. Open Source Software
2. Unit testing
3. Persistance layer: object-relational mapping tools
4. Improving software quality: automatic testing
5. Parallel programming with .NET

So, what if I want to develop my own personal project and I require a RDBMS (Relational DataBase Management System)? Oracle and MS-SQL are out of the question because of their high cost. MS-SQL Express has great limitations, so, although it is free, we won’t be considering it for our purpose. Which is the best open source RDBMS?

Today’s most known open source RDBMS are MySQL and PostgreSQL. PostgreSQL is considered to beat MySQL in the features war. This used to be true some time ago, but it’s no longer the case anymore. 99% of the needs you will have with your RDBMS will be covered by both MySQL and PostgreSQL. Still, there’s many people who think that MySQL has improved a lot, but it’s just not PostgreSQL.

If you want to compare performance, fans of both systems will tell you their RDBMS is faster than the other one. On one hand, PostgreSQL has been recently paying attention to speed, and has been making its product faster and faster with every release. On the other hand, MySQL proponents say that, if configured properly, MySQL’s MyISAM tables are indeed lightweight and make for a faster database.

But probably, the most important thing to consider when choosing which RDBMS you should use, is which one is easier to use. I can tell you that previous Oracle experience will make you feel at home and comfortable with PostgreSQL. Still, the MySQL community seems to be much bigger than PostgreSQL’s, so, should you require some assistance when developing your project, if you’re using MySQL chances are that you will get quick help from them.

MySQL is licensed under the GNU GPL, but offers an alternative commercial license for those who don’t want to be restricted by that license. PostgreSQL uses the BSD license, which stipulates that the credits have to be maintained, but beyond that you can do whatever you want with it.

But, after all, it just all comes down to personal tastes. Just choose whatever you like and whichever you think might fit your needs better. What might be the best for one person, might be a bad choice for another.

Check these links for more info:

• Open Source Database Feature Comparison Matrix
• Comparison of RDBMS

Related posts:

1. Sluggish database view? Materialize it!
2. Entity Framework
3. Persistance layer: object-relational mapping tools

The curious case of the mutating scope

Ok, now imagine we have some fancy widget in our class and we want to interact with it. There are many widgets which redefine the this keyword to its instance instead of ours. For this case, we might want to be able to access our instance instead of the widget instance. We’ll need to redefine the scope in which the function is being executed. To do so, we can use the following function:

// Creates a new function and returns a reference. This new function has its scope set to 'newScope'
this.setScope = function (originalFn, newScope) {
   return function () { return originalFn.apply(newScope, arguments); };
};

We could just use the apply method on our original function, but I prefer this way since its more comfortable to work with parameters like this.

Be careful when using this, since this is a double-edged sword. By accessing our class scope we have all our data available. But we won’t have the widget’s scope available anymore. So make sure you don’t need to access the widget’s scope before changing the scope of the event handler.

Accessing your instance from the global scope

When you do something like

var Peter = new Person();

you’re creating a new instance of the class Person. And the variable Peter is just a pointer to the instance, not the instance itself. Peter is the way we have to access that instance from global scope: it’s just a pointer. But we have no way to know the name the pointer to the instance was given from within the instance itself. This means, we have no way to know that Peter is the way we have to access the instance from global scope.

So, if we’re ever in the need of calling a method from a global scope, we’ll need to keep an array of instances ourselves. We could be doing something like:

var Person2 = function (name, surname, age) {
	var _name, _surname, _age;

	this.showData = function () {
		var str = new String();
		str = "Name: " + _name + " - ";
		str += "Surname: " + _surname + " - ";
		str += "Age: " + _age;
		alert(str);
	};	

	// ---- Constructor -----------------------------------------------
	_name = (typeof name === "undefined" ? "John" : name);
	_surname = (typeof surname === "undefined" ? "Smith" : surname);
	_age = (typeof age === "undefined" ? 20 : age);

	// Store pointers to all instances of this class, so we can access their
	// context from global code
	var _instanceIndex = Person2._instances.length;
	Person2._instances[_instanceIndex] = this;
};
Person2._instances = new Array();

So now we have an array containing all the different instances of the object:

var Peter = new Person2();  // Equivalent to Person2._instances[0]
var John = new Person2('John', 'Smith');  // Equivalent to Person2._instances[1]

This is useful if you’re declaring some event handlers in the HTML code. Something like:

<div id="myDiv" onclick="Person2._instances[1].showData();">Hello world!</div>

CAUTION!! This is not something I would recommend. This is not a good practice in JavaScript. Behaviour should be separated from the content, and with this you’re just mixing both together.

I’m just showing this as a possibility, in case you’re in the need of something similar. But be aware that by using onclick event handlers like this, you’re making your code less readable and less maintainable. Be careful!

Well, now you have to start practicing all these concepts you’ve just read. Start doing some JavaScript programming. The more you do it, the better programmer you’ll become.

Related posts:

1. Object Oriented JavaScript II: the pattern
2. Object Oriented JavaScript I: the basics
3. JavaScript best practices I

The first feature we need to implement is private and public members. Using closures, this is easy to achieve:

var Person = function () {
	// Private elements
	var _name, _surname, _age;

	// Public elements
	this.getName = function () {
		return _name;
	};
	this.setName = function (newName) {
		_name = newName;
	};
	this.getSurname = function () {
		return _surname;
	};
	this.setSurname = function (newSurname) {
		_surname = newSurname;
	};
	this.getAge = function () {
		return _age;
	};
	this.setAge = function (newAge) {
		_age = newAge;
	};
};

By declaring functions inside the outer function Person, we’re creating a closure which makes the elements _name, _surname and _age inaccessible by members which are not inside the Person function. On the contrary, all elements declared with the this keyword will be accessible from outside of the Person function.

If we want to set some code to be executed when this class is instantiated, we can do so anywhere inside the Person function:

var Person = function (name, surname, age) {
	// Private elements
	var _name, _surname, _age;

	// Public elements
	this.getName = function () {
		return _name;
	};
	this.setName = function (newName) {
		_name = newName;
	};
	this.getSurname = function () {
		return _surname;
	};
	this.setSurname = function (newSurname) {
		_surname = newSurname;
	};
	this.getAge = function () {
		return _age;
	};
	this.setAge = function (newAge) {
		_age = newAge;
	};

	// Default constructor
	this.setName(typeof name === "undefined" ? "John" : name);
	this.setSurname(typeof surname === "undefined" ? "Smith" : surname);
	this.setAge(typeof age === "undefined" ? 20 : age);
};

This way, we’re creating constructors.  If the name, surname and age variables are given a value when this class is instantiated, that value will be assigned to the private properties; if not, then default values will be used. So we can now check how what we’ve written behaves so far. I’ll use the Firebug console to check what our JavaScript does:

>>> var John = new Person()
>>> John.getName()
"John"
>>> John.getSurname()
"Smith"
>>> John.getAge()
20
>>> var Peter = new Person("Peter", "Jackson")
>>> Peter.getName()
"Peter"
>>> Peter.getSurname()
"Jackson"
>>> Peter.getAge()
20

Notice how private properties get the the default values if we instantiate the class with no values for the constructor.

So we now have private and public elements, the most basic features of object oriented techniques. But there’s actually different kinds of public properties. Depending on how you declare them, some public elements will actually behave slightly different:

var Person = function (name, surname, age) {
	// ---- Private members ------------------------
	var _name, _surname, _age;

	// ---- Public, privileged members ------------------------
	// Privileged members are exposed through the API and have access to
	// private members

	this.getName = function () {
		return _name;
	};
	this.setName = function (newName) {
		_name = newName;
	};
	this.getSurname = function () {
		return _surname;
	};
	this.setSurname = function (newSurname) {
		_surname = newSurname;
	};
	this.getAge = function () {
		return _age;
	};
	this.setAge = function (newAge) {
		_age = newAge;
	};

	// ---- Default constructor ------------------------
	this.setName(typeof name === "undefined" ? "John" : name);
	this.setSurname(typeof surname === "undefined" ? "Smith" : surname);
	this.setAge(typeof age === "undefined" ? 20 : age);
};

// ---- Public, non-privileged members ------------------------
// All elements included in the prototype are exposed through the API and
// do not have access to private members.
// All instances of this class will have these members available.
Person.prototype.getPersonData = function () {
	var str = new String();
	str = "Name: " + this.getName() + " - ";
	str += "Surname: " + this.getSurname() + " - ";
	str += "Age: " + this.getAge();
	return str;
};

// ---- Public, static member for current instance ------------------------
// Members defined like this are related to the object itself, not to instances.
// These members have no means of accessing instance or private data.  They can't
// access instance data because they don't have the "this" operator set to any
// particular instance.
// These members relate to the instance in which they are defined. Since we're defining
// them for the class definition, instances of this class will not have these members
// available.
Person.AreEqual = function (p1, p2) {
	return p1.getName() === p2.getName() &&
			p1.getSurname() === p2.getSurname() &&
			p1.getAge() === p2.getAge();
};

Notice how depending on how you declare your public members, they will have different access level to the information within your instance:

• Members declared inside the closure with the this keyword are privileged: they have access to private members.
• Members declared with the prototype keyword are non-privileged: they do not have access to private members. These members will be available in all instances of this class.
• Members declared like “class name” + “.” + “member name” are public static members for the current instance. They don’t have the “this” operator available, and other instances of this class will not have these members available.

So, here’s how our class behaves:

>>> var John = new Person()
>>> John.getPersonData()
"Name: John - Surname: Smith - Age: 20"
>>> Person.AreEqual(new Person(), John)
true
>>> var Peter = new Person("Peter")
>>> Person.AreEqual(John, Peter)
false
>>> John.AreEqual(John, Peter)
TypeError: John.AreEqual is not a function { message="John.AreEqual is not a function", more...}

Notice how the AreEqual method is only available for the object Person, not for its instances.

Ok, now we’ve covered public and private elements, constructors and the different access levels public members may have. We’ve gone through all we need to write object oriented code. But keep on reading to see some tips about OO code in JavaScript.

Stay tuned for my next post!

Related posts:

1. Object Oriented JavaScript III: some tips
2. Object Oriented JavaScript I: the basics

Until AJAX techniques emerged, JavaScript was not seen as an application development platform. It was treated merely as a scripting language to implement minimal dynamic web page behavior. Up till not too long ago, all the JavaScript I needed to write was just a few lines of code to make some validations, a few animations and some AJAX calls… but this has definitely changed today. The number of JavaScript lines I am writing nowadays for the web apps I’m developing are counted in the thousands. Heck, the last module I developed at work contained more than 12000 lines of JavaScript code! This means that I can no longer just write code without order. I need to have some logic behind the process of writing code. And this is when object oriented techniques come into play.

Much has been written about JavaScript and how to use its object oriented features. The thing is, although JavaScript has some object oriented (OO) features, how to use them is not a trivial matter. JavaScript (JS) is quite different from other OO languages like C# or Java, so if you’re coming from these types of languages, after some while you’ll realize that JS behaves differently in a few ways. It’s not that it’s better or worse, it’s just different. And if you ever want to get to master JS, you’ll need to be aware of them.

There’s a bunch of different approaches on how to use OO features and techniques. The most widely spread methodology for writing classes is the module pattern, made popular by the YUI JavaScript library.

I’ve spent some time digging through the internet trying to find what the best pattern for OO JavaScript is. Unfortunately, there doesn’t seem to be any kind of standard, and people just implement whatever better suits their needs. So, looking around, I came up with my own pattern for writing classes and object oriented JavaScript. It is somehow derived from stuff that I’ve seen throughout the web, and with some additional features I consider useful.

But before explaining this pattern, you first need to understand some basics about JavaScript:

JavaScript has loose typing. At any given time, the type of a variable is the type of whatever is assigned to it. I could perfectly do something like:

var myVariable = 34;
myVariable = "Hi there!";

And no error would be thrown.

JavaScript has anonymous functions. To show this concept I’ll use the function setTimeout, which is used for executing some code after some specified amount of time:

function sayHi() {
   alert("Hi!");
};
setTimeout(sayHi, 1000);

This shows a message with the text “Hi!” after 1000 ms. The same thing can be achieved by an anonymous function:

setTimeout(function () { alert("Hi!"); }, 1000);

JavaScript has function pointers. The previous function can be expressed as:

var sayHi = function () {
   alert("Hi!");
};

And it would still be called in the same way, sayHi().

JavaScript has closures. Now, this is a little bit tricky. Closures are something which is not fully understood by all programmers. But they really aren’t all that complicated. Let’s take a look at them:

A “closure” is an expression (usually a function) that has variables together inside an environment that binds those variables. In other languages, when a function is called, a new stack frame is created and then destroyed when the function completes. So, if a function is called 3 times, 3 different stack frames are created with 3 different set of local variables. JavaScript behaves differently. In JS, it is as if the stack frame for the closure was not deallocated from memory when the function returns. It’s as if it was given a static piece of memory and always stayed there. So if you call the closure 3 times, the same set of local variables are accessed, having the same value. That means, having the last value they had the last time that closure was called.

An example to clarify things a little. Take a look at this piece of code:

function initGlobalVariables {
   var someNumber = 123;
   var someString = "Hello World!";
   var someFunction = function () { alert(someString); };
};

By writing a function inside some other function, we’re creating a closure. The scope of the inner function is the outer function: this means that the function assigned to someFunction can access the variables someNumber and someString. And every time we call the function assigned to someFunction, the variables will not be created and destroyed: they will remain there with the last value they had.

Just remember these key facts for closures:

• A closure is the local variables for a function – kept alive after the function has returned.
• Whenever you use a function inside another function, a closure is used.
• Whenever you call the outer function, a new closure is created.
• Whenever you call an inner function of the closure, no new closure is created: you access the existing closure with the last values they had the last time you exited an inner function of the closure.

The this keyword refers to the closure within it is located. The value of the this keyword refers to the scope of the function. That is, the closure within it exists.

Ok, with this we’ve covered the very basics of JavaScript we need to understand object oriented techniques. In my next post I’ll start covering the pattern, so stay tuned!

Related posts:

1. Object Oriented JavaScript II: the pattern
2. Object Oriented JavaScript III: some tips
3. JavaScript best practices I
4. Persistance layer: object-relational mapping tools
5. JavaScript best practices II