Update (2009.03.27): From Sense/Net 6.0 Beta 3 Portal File System (PFS) is called Sense/Net Content Repository (SNCR)
The following article is intended to give an insight on the structure of Sense/Net 6.0 focusing on object storage and management. This topic is a rather complex one, however, understanding this chapter is vital for efficiently working with objects stored in the Portal File System.
The architecture model
The Sense/Net 6.0 storage architecture consists of 4 separate layers.
These layers are:
This layer consists of database servers. Raw data is stored and retrieved at this level. The information is then passed back to the PFS layer for further processing.
Portal File System
The PFS is the layer responsible for converting raw data fields into nodes with PFS properties. It also manages versioning and security and supports basic methods like copying and moving objects.
Portal Services Layer
Nodes stored in the PFS are converted into either generic or typed objects: so-called contents. Contents contain properties or fields within this layer.
The Portal Services layer implements node related business logic on top of the PFS and also is in charge of content validation.
Contents from the Portal Services layer are visualized within this layer. This is the topmost layer where application logic and user interfaces are implemented. Portlets, applications and the Portal Explorer are located within this layer.
Objects and properties within the model
The logic behind separating the 4 layers is better understood when observing what properties and objects represent at within each layer.
Portal File System
A PfsProperty is a property of an object that stored within the database. The PfsProperty maps itself automatically to the database cell (mapping could also be done to multiple database cells however this is a very rare scenario).
A Node is a persistent object, consisting of PFS properties and supporting basic persistency, versioning and security related methods.
Nodes have some vital built-in properties (e.g. Id, Name, Path, Parent) and a list of their PfsProperties.
Certain object properties needn’t be stored in the PFS, they might be calculated form other PfsProperties or may be obtained remotely e.g. using web services. A Property represents either of these.
ContentHandlers are inherit from Nodes, and define Properties (meaning either PfsProperties or custom, non PfsProperties). Business logic can be added to loading and saving these of the properties or the object itself.
Therefore a ContentHandler is a Node with business logic and some additional properties not necessarily stored in the PFS.
A field is a set of properties with validation logic. Fields may be mapped to multiple Properties (a good example of this is the WhoAndWhen Field type which consists of a Reference and DateTime property). In most cases, however, Fields are mostly mapped to a single Property.
A Content represents the object with the validation logic included. It holds a reference to a ContentHandler therefore accessing the properties of the object is usually done through this object.
As a result a Content is an object with a wide range of properties, business logic (both inherited from the ContentHandler) and built-in validation.
A FieldControl is a visual representation of a Field. It makes adding, editing and viewing of a Field possible for the end user.
A ContentView visually represents the object and makes adding, editing and viewing possible for the user.
Before developing it is important to understand what the different object types at each hierarchy level represent. Familiarizing yourself the terminology (Node, ContentHandler, Content, ContentView and PfsProperty, Property, Field, FieldControl) is also needed for being able to create and manage custom objects. After doing so, however, developing will be rapid and simple as you'll be experiencing this in examples to come.