Using live views is not limited to GUI. In a more general way, live views enable a declarative style of programming which we tentatively call view-oriented programming. Non-GUI, batch processing code can also be made declarative using live views.

Generally speaking, any application operates on some data, and any data can be seen as either based or derived data. Base data contains the main objects your application is dealing with, like Customers, Orders, Employees, et cetera. Those objects (collections containing all objects of a certain class, sometimes called the extent of a class) are the objects that your application modifies when it needs to make some change in the base data. But applications rarely operate on this base data directly, they rarely directly operate on the entire extent of a class. Usually they filter and shape those extents and combine them together to get to a slice of data they need for a particular operation. This shaping/filtering/joining/slicing of data is the process of getting derived data (as opposed to base, underlying data). Before the emergence of LINQ, it was done by purely procedural code, with all the ensuing complexity. LINQ made it declarative, which is a big step forward. But, although declarative, it is not live, not dynamic, and does not react to changes in base data automatically. Accordingly, its reaction to change is not declarative; the programmer needs to react to changes in procedural, imperative code. Complexity is diminished by LINQ, but reacting to change remains complex. And reacting to change is pervasive because change is everywhere.

LiveLinq live views make reacting to change declarative too, thus closing the circle of declarativeness. Now entire applications, not just GUI, can be made virtually entirely declarative.

To give just a small example, we can consider a sample in the LiveLinqIssueTracker demo. It has two operations performed on some issue data:

1. Assign as many unassigned issues to employees as possible, using information on pending issues, product features (every issue belongs to a feature) and assignments.
2. Collect information on open issues for given employees.

Each of these two operations (and in a real application there is, of course, many more operations like this) works on data shaped by a query with joins (see the actual queries in Live Views How To: Use Live Views to Create Non-GUI Applications as a Set of Declarative Rules Instead of Procedural Code). Both operations can be performed more than once during program execution. Data is changing while these and other operations on data are performed. Live views used to implement these operations change automatically with that changing data, so the operations can be kept simple and completely declarative, and as a result of that, robust, reliable and flexible, easily modifiable when business requirements change.

There is nothing else needed for this style of programming in addition to what we already know about how to create live views.