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.

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").

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.

About the Author

Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at http://blog.learningtree.com/tag/ui/.

comments powered by Disqus

Featured

  • Creating Reactive Applications in .NET

    In modern applications, data is being retrieved in asynchronous, real-time streams, as traditional pull requests where the clients asks for data from the server are becoming a thing of the past.

  • AI for GitHub Collaboration? Maybe Not So Much

    No doubt GitHub Copilot has been a boon for developers, but AI might not be the best tool for collaboration, according to developers weighing in on a recent social media post from the GitHub team.

  • Visual Studio 2022 Getting VS Code 'Command Palette' Equivalent

    As any Visual Studio Code user knows, the editor's command palette is a powerful tool for getting things done quickly, without having to navigate through menus and dialogs. Now, we learn how an equivalent is coming for Microsoft's flagship Visual Studio IDE, invoked by the same familiar Ctrl+Shift+P keyboard shortcut.

  • .NET 9 Preview 3: 'I've Been Waiting 9 Years for This API!'

    Microsoft's third preview of .NET 9 sees a lot of minor tweaks and fixes with no earth-shaking new functionality, but little things can be important to individual developers.

  • Data Anomaly Detection Using a Neural Autoencoder with C#

    Dr. James McCaffrey of Microsoft Research tackles the process of examining a set of source data to find data items that are different in some way from the majority of the source items.

Subscribe on YouTube