The Practical Client

Defining Entity Objects in TypeScript

The first step in building an object in TypeScript is defining the objects with which you'll be working. I'll show you how to do that, as well as look at some of the TypeScript support for the latest versions of JavaScript.

• By Peter Vogel
• 05/28/2013

As I outlined in my first Practical JavaScript column, my initial focus in this space will be on exploring Microsoft TypeScript. TypeScript is still in beta, as I was reminded when the copy of Visual Studio where I'd installed version 0.8.3.0 lost its TypeScript project template and stopped automatically compiling my TypeScript files. However, I solved this by switching to using the compiler from the command line (for background on a compiler feature that's only available from the command line, see "Converting to JavaScript and Supporting ECMAScript 5 Properties").

var AdventureWorksEntities;
(function (AdventureWorksEntities) {
  var Customer = (function () {
    function Customer(Id, FirstName, LastName) {
      this.Id = Id;
      this.FirstName = FirstName;
      this.LastName = LastName;
    }
    Customer.prototype.getId = function () {
      return this.Id;
    };
    Customer.prototype.setId = function (Id) {
      this.Id = Id;
    };

tsc --target ES5 AdventureWorksEntities.ts

export class Customer implements ICustomer {
  constructor(public Id: number,
              public FirstName: string,
              public LastName: string) {  }

  get id() { return this.Id;}
  set id(Id: number) {this.Id = Id; }

(function (AdventureWorksEntities) {
  var Customer = (function () {
    function Customer(id, FirstName, LastName) {
      this.id = id;
      this.FirstName = FirstName;
      this.LastName = LastName;
    }
    Object.defineProperty(Customer.prototype, "Id", {
      get: function () {
        return this.id;
      },
      set: function (Id) {
        this.id = Id;
      },
      enumerable: true,
      configurable: true
    });

I decided to use the AdventureWorks database for this project because it's generally available (and often known to developers from examples in Microsoft documentation). My application will allow users to select a customer from a dropdown list and see all the sales orders for that customer.

Often, my first server-side step in building an application is to write the entity classes that represent the tables my code will be using. On the client side, it's often to define the data transfer object (DTO) classes that will move my data from the server to the client. For this application, I'll need a Customer object to populate the dropdown list of customers. When the user selects a customer, I'll need a more complex object to transfer additional information about the selected customer, along with a collection of SalesOrderHeader objects representing all the sales orders for the customer. In this column, I'll work through the TypeScript required to define the Customer and SalesOrderHeader classes that I'll need, and try to define some best practices.

Defining Classes with TypeScript
In TypeScript, even before defining my classes, I define a module to hold my classes. Enclosing my classes in a module creates the equivalent of a server-side namespace to prevent name collections with other JavaScript code that may also define a Customer or SalesOrderHeader class. Here's what I used:

module AdventureWorksEntities {

Within my module, I define my entity classes. I define a constructor for my object that accepts a value for each column on the table. Because I'm using TypeScript, I can specify a datatype for each of the constructor's parameters:

export class Customer implements ICustomer {
  constructor(public Id: number,
    public FirstName: string,
    public LastName: string) {  }

I've flagged this class with the export keyword to make it available outside the module (in many ways, export is the equivalent of public in languages such as C# and Visual Basic).

TypeScript will automatically define a field to back up each parameter in my constructor, so I don't have to explicitly define a class-level variable to hold the value for each parameter. To make those fields available to the external world, I do need to define a get and set method for each value (again, with datatypes for my parameters):

public getId() { return this.Id; }
public setId(Id: number) { this.Id = Id; }
public getFirstName() { return this.FirstName; }
public setFirstName(FirstName: string) { this.FirstName = FirstName; }
public getLastName() { return this.LastName; }
public setLastName(LastName: string) { this.LastName = LastName; }

Even with IntelliSense, that's a lot of typing for any class that has a lot of values to expose -- all that typing reminded me how much I like auto-implemented properties (and I'm already considering creating a code-generation add-in to simplify this). Having typed all this code in, I'll certainly want to use it in other projects, so I put these definitions in their own file, which I called AdventureWorksEntities.ts.

With my entities defined my next step is obvious: Set up for unit testing, which, among other issues, is going to mean integrating TypeScript files. I also consider it a best practice to define interfaces for my classes, which I haven't done here. That's all in next month's column.