eXtensions Framework. The Origin of XF

This topic describes the causes to create the eXtensions Framework.

Table of content:

  • Contradictions between developers and users
  • Inheritance vs XF
    • - Examples

Contradictions between developers and users

There is a certain discrepancy between the views on the application from the developer and the end user.

To implement the application, the developer often uses an object-oriented programming tools. Therefore, the developer is looking at the system (i.e. the data model of the system) as a class hierarchy in which classes are inherited from others.

In terms of end-user application consists of documents, reports, classifiers, buttons, and other elements that are involved in automation of its business processes. And the user is absolutely indifferent to the inheritance hierarchy and what abstract classes were used.

In other words, there are two views on the final application:

  • from the inside: it is a complex system of related classes.
  • from the outside: it is a set of business entities, documents, classifiers, reports etc.

Any application has its own life cycle. When the state of the application is fixed and does not require any new features to add or exclude the ready, both parties (developers and users) may be considered satisfied. But for the majority of enterprise customers it is required to adapt the product for specific needs. In the general case, it may require modification of any object: reports, business processes, functions etc. But most problems arise when the need to expand the data model. Effective solution of the problem determines the efficiency of the application as a whole, since changes to the data model affects the structure of the database.

XF offers a special adjusted approach to the design of the data model, which eliminates most of the controversy.

Inheritance vs XF

When developing applications, there is "Code First" approach to designing a business model, this means that the developer begins with the implementation of persistent business entities, which define the data model in database. Therefore, to extend the data model is required to declare a new persistent entities. At the same time we can say that we have two ways how to do it.

The first way is the most obvious to the object oriented programming. This is to create a descendant to the current entity and to implement required additions in descendant. In the system simultaneously exist both business entities that misleading end user.


The second way is more obvious for structured programming. This is to create an extension to the current entity and to implement required additions in extension. In this approach, the additional business entity is not created.


Thus, should be discussed the vertical and horizontal functionality expansion. Each of the methods has shortcoming

that are listed in the table below (marked with a "-" sign).

Positions to compare





New entity will appear



It is difficult to use in the code: declare, access



When expanding the entity with the different modules the conflict will occur.



Use in queries



Use in reports



Using a horizontal strategy more correctly even with the existing shortcomings.

Example 1

The diagram below shows an example of using a horizontal strategy


Abstract classes BaseClass1 and BaseClass2 are implemented in the common module (for definiteness, we assume that it is Xafari.BC module). Entity1 is an Entity implemented in the depended module (for definiteness, we assume that it is Xafari.BC.CD module). Ext1 and Ext2 is Extensions of the Entity1, these are implemented in custom extra modules, this assumes that the customer uses both extra modules simultaneously.

NewEntity1, NewExt1, NewExt2 classes are aggregations, these exists only for individual customer (or for individual configuration). These classes will be generated automatically when the application starts. The user is always working with only one type of business object, as shown in the figure below. The rest are additional to Class1.


Horizontal strategy allows to extend a business model practically with no restrictions and receive the resulting models of varying complexity (see figures below).

Example 2

Here the Class1 Entity is extended with three Extensions implemented in four additional modules. Moreover, each Extension in turn extends also in other modules.