View Composer

View Composer is a Views-like module, built over a full OOP API strongly interfaces oriented (attempt to be as near as it can be from the SOLID principles).
Basically uses some well-known patterns and take strong design orientation to get rid of stupid problems:

• Built over the OOX module ObjectStream interface and API as a backend, which makes configured backends re-usable from bundle to bundle
• Built over the same module Formable API as a UX helper
• Built over the XoXo module Storage backend for persistence (which can be proxied as entities)
• Uses the Null Object pattern at normal runtime in order to avoid any WOSD or end-user ugly crashes
• Object streams are backends, while the defined frontend interface is context agnostic and pragmatically render objects given by the stream using a formatter. The formatter is everything agnostic except the object it renders. The concept of bundles ties the lot configuration and handles persistence for the objects, and will allow you to place it anywhere in the site
• Uses a somewhat random but working implementation of the decorator pattern in order to decorate the frontend display
• Datatype is at the center of the design, a bundle will use a stream as backend, that defines a datatype, then all other components selection will be restricted by this datatype. Incompatible frontend, backend and formatters will make the system throw nice exceptions therefore cutting down execution time to nothing in case of errors

It does not provides as much as features as Views, since it's quite new. Basically it's absolutely not a query builder, and it doesn't provide the filtering facilities such as Views. Some use cases may be the same while generally speaking, they are not. This module is much more API oriented than UX oriented.
Same for fields, while a database backend could be easily made out of the module, it's not part of the design. Field-based design could be implemented in a Object Stream API based module and would remain independent from VC.