The bottom line is that the Model is an extension of the old Record. Profit.

From my post (though the guy's asking more specifically about Proxies. It's in the answer, I think.) on StackOverflow:

I'm coming from ExtJS 2.2 [sic] to 4, and the Model behavior and terminology threw me for a loop too.

The best quick explanation I can find is from this post in the "Countdown to ExtJS 4" series on Sencha's blog. Turns out a Model acts like it does because it's "really" a Record.

The centerpiece of the data package is A Model represents some type of data in an application - for example an e-commerce app might have models for Users, Products and Orders. At its simplest a Model is just a set of fields and their data. Anyone familiar with Ext JS 3 will have used, which was the precursor to

Here's the confusing part: A Model is both a model for the data you're using and a single instance of an object following that model. Let's call its two uses "Model qua model" and "Model qua Record".

This is why its load method requires a unique id (full stop). Model qua Record uses that id to create RESTful URLs for retrieving (and saving, etc) a single Record worth of data. The RESTful URL convention is described here and is linked to in this post on Sencha's blog that talks specifically about Model usage.

Here are a few RESTful URLs formed to that standard to get you familiar with the format, which it appears ExtJS' Model does use:

Operate on a Record with id of 1

GET /people/1 <<< That's what's used to retrieve a single record into Model

return the first record with id of 2

DELETE /people/2

destroy the first record with id of 7

POST /people/7?_method=DELETE

Etc etc.

This is also why Models have their own proxies, so that they can run RESTful operations via that URL modified to follow the conventions described in that link. You might pull 100s of records from one URL, which you'd use as your Store's proxy source, but when you want to save what's in the single Model (again, think "Model qua Record" here), you might perform those Record-specific operations through another URL whose backend messes with one record at a time.

So When Do I use Stores?

To store more than one instance of that Model, you'd slap them into a Store. You add lots of Models quaRecords into Stores and then access those "Models" to pull data out. So if you have a grid you'll naturally want to have all that data locally, without having to re-query the server for each row's display.

From the first post:

Models are typically used with a Store, which is basically a collection of Model instances.

And, of course, the Stores apparently pull info from Model qua Model here to know what they're carrying.