When working with EPiServer we're used to having a single class to work with (if not using PageTypeBuilder), the PageData class. At first glance it's equivalent in Umbraco is the Document class, but after looking closer you'll see that there is one enormously important difference, caching.
In EPiServer, we get all PageData objects from the DataFactory, since EPiServer implements a factory pattern. It's also implemented as a singleton, making it very simple to interact with. We get the page by passing a PageReference to the factory, getting the page we want. By default the DataFactory returns the currently published version of a page. In Umbraco, we instead call the constructor on the Document object, by passing it an ID of the page we want. A big difference here is that the Document API by default returns the latest version of that page, regardless if it's published or not, if a certain version is required, specify it by passing the version Guid.
Another difference between the PageData and Document objects, is caching. The PageData object you get from the DataFactory is always cached (except when getting pages with FindPagesWithCriteria, but more on that in another post), whereas the Document object is never cached. For this reason, we only work with the Document API when we want to programatically change data. For a cached page in Umbraco, we use the Node API.
In EPiServer, the PageData object is read-only, when we want to change a page, we call CreateWritableClone() on the PageData object, getting a writeable copy of our object, that we can change all we want. When we're done, we pass it back to the DataFactory for saving and/or publishing. In Umbraco, this is not as straight-forward. The Document is always open for changes, and changing a property will persist that change to the database immediately. Properties for an EPiServer PageData object is accessed throught its index property, by property name, like MyPageData["MyProperty"]. Getting a property on the Document object is done with a call to MyDocument.getProperties("MyProperty"), however, this performs a call to the database as soon as you access the Property.Value property. What this essentially means, is that each proeprty is saved as soon as you set its value, calling Document.Save() fires the BeforeSave and AfterSave events, updates the UpdateDate property, and the preview XML. This is important to know. Calling Document.Publish() performs different task related to publishing, but it doesn't push your data to the content cache, for this you need to call umbraco.library.UpdateDocumentCache(int) passing it the ID of the Document. This also ensures that any other servers, if your site uses load balancing, also performs the cache update.
There are a number of methods to get cached content in Umbraco, the old-school way is to use the Node API, most commonly used via XSLT in Macros, but it's also available from code. Another way is to use Linq2Umbraco, that gets cached, typed, instances of your content. It has excellent performance, and if you're more comfortable with using C#/VB for your coding, this is probably the way for you. As I write there is also support for using Razor in Umbraco, and I dare say that it may make XSLT in Umbraco obsolete. It's the new black, and it's friggin' awesome :)
There's a great set of wiki-articles called The Umbraco API Cheat-sheet. Amongst others, it clearly describes the difference between a Node and a Document.
As usual, all and any comments, suggestions and additions are more than welcome.
(This post was previously published here.)