When we talk about the concept of Models in object-oriented programming, we’re usually referring to a class that is a representation of the data stored in the database.

That is is, when information is stored in rows and columns, we populate a class, its attributes, and so on with that information so that we’re able to pass it around the application, manipulate it as needed, and then possibly serialize the data back to the database.

But in a web application, it’s fair to assume that the model might need to be possible to the front-end to be used. That is, imagine a front-end request making a call to the server, requesting a model (or a collection of models), and then rendering them on the front-end.

Though this particular post isn’t code-oriented, I still think it’s worth thinking through the process of translating a model from the server and then rendering it on the front-end of the web application.

Working with Models and Web Applications

Imagine, for a moment, that your application has an Employee model. This model may include a variety of attributes, but it’s safe to assume that all employees would have:

  • a first name,
  • a last name,
  • an employee ID,
  • and an email address

How this information is stored in the database isn’t altogether irrelevant, but it’s not that important for this discussion.

For example, perhaps there’s a single record that contains all of this information stored in a JSON string. On the other hand, perhaps there’s an employee table where each row represents an employee, and then each column represents an attribute.

The details how of how the information is translated from the database (or, more generally, the data store) to the class isn’t as important.

Usually, however, we’ll see something like this:

  1. There is a class that requests the information,
  2. The information is passed to a Simple Factory,
  3. The Simple Factory instantiates the Model,
  4. The Model is then passed to the third-party class that requested it.

From a pictorial standpoint, you may view it like this:

Working with Models and Web Applications

From this point, the Model is passed throughout the application. But this is where the initial point of this post comes into play: How do we pass an instance of the Model (or a collection of Models) to the front-end of the application?

The Flow of the Web Application

For the sake of the keeping it simple, let’s assume that we’re going to be using a single model and then, should I revisit this concept from a code standpoint, we can dive in a bit more.

The general flow of a web application will be something like this, though:

  1. A user triggers an action that requests an instance of the model,
  2. The front-end makes a call to an endpoint on the server,
  3. The server reads the requests and verifies that it’s valid,
  4. Then sends a representation of the model to the front-end.

Other developers may disagree (which is always welcome and worth discussion, in my opinion), but I’ve found that serializing the instance of the model into JSON makes it much easier to work with on the front-end because of JavaScript functionality as it relates to, ahem, JSON.

Working with Models and Web Applications: JSON

In other words:

  1. we take the model,
  2. serialize it to JSON,
  3. send it across the wire,
  4. then de-serialize it on the front-end into a JavaScript representation of itself.

This allows us to manipulate it much as we would on the server-side; however, we’re dealing with a JavaScript object. Furthermore, it allows us to also make certain changes and send the information back to the server in a different state from which it was sent.

Ultimately, this allows us to save the data back to the database.

A High-Level Perspective

And that’s the high-level life cycle of passing information from a database to a model to the front-end and back again.

Often, though, it helps to see this in code, so perhaps in a future post, I’ll provide a series of articles that can walk through how to do this.

In the meantime, though, it should not be difficult to translate your implementations into the Model-Serialization-Request-Send workflow as outlined in this post.