CodeFluent Entities Documentation
The CodeFluent Entities API
See Also Send comments on this topic.
CodeFluent Entities > Architect Guide > Aspect Oriented Design > The CodeFluent Entities API

Glossary Item Box

The two main benefits of aspects are that:

For instance, say you developed an application containing hundreds of tables, and suddenly you are asked to be able to track values inserted in some columns of most of your tables.

In practice a way to do it would be to:

Sure we could pass over all entities in our model and add the rule as well as the code which saves the tracked properties in the Track table, but this would be a tedious task. Instead, developing an aspect to automatically add the described elements to our model would prove to be way more efficient. Not only, would we let the tool generate all the desired code, but in addition wrapping this feature into an aspect would allow us to reuse it on other projects.

Developping an aspect such as the Tracking one implies to use the CodeFluent Entities API to modify the in-memory model inferred by CodeFluent Entities. Therefore, this article details the CodeFluent Entities API.


The CodeFluent Entities API

The root object of the CodeFluent Entities API is the Project class: everything starts from it.

From the Project class, you'll be able to manipulate the entire inferred meta-model:

Please note that at this stage, we're still manipulating platform independent concepts.

The following diagram illustrates the main concepts available in the API to manipulate the inferred business object model:


Note: The diagram is not an exhaustive list of all available concepts.

The following diagram illustrates the main concepts available in the API to manipulate the inferred database:


Note: The diagram is not an exhaustive list of all available concepts.

The following diagram illustrates the main concepts available in the API to manipulate the inferred UI:



Note: The diagram is not an exhaustive list of all available concepts.


Mx, M² and M³

As explained in the Overview, a CodeFluent Entities model is a bunch of XML files which are parsed and from them a meta-model will be inferred: XML nodes you defined (e.g. <Product>) will become CodeFluent Entities concepts such as Entities, Enumerations, Producers, etc. which themselves are in fact more global concepts as nodes, and attributes. Therefore, we can say CodeFluent Entities' models are composed of three levels:

In a nutshell, Mx corresponds to the XML and is parsed, whilst M² and M³ are inferred from Mx.

Dynamic modeling occurs throughout the inference stage, therefore aspects can work on Mx and other meta-models (M², M³).

Using the API (CodeFluent.Model.dll) you can access all levels (Mx, M², M³) of the model:

Note: The CodeFluent Entities API is discussed with more details in the following article: The CodeFluent Entities API.

Moreover, CodeFluent Entities' schema isn't restrictive. This means that you can add your own XML namespace in your model to add extra attributes, and then access those custom attributes in your aspect.



As explained hereabove, using XPath expressions you can work on the Mx level since you're manipulating standard XML classes (e.g.: XmlDocument, XmlElement), but you can also so work on the M³ inferred model as well. This is possible since the CodeFluent Entities API implements a XPathNavigator allowing to navigate through the API.

You can actually get a visual representation of this using the Model Grid in the Modeler (in the solution explorer, select the Model node, right-click, and Show Model Grid):


The Model Grid uses what we call selectors which are basically XPath expression ran on the M³ model. Built-in selectors are:

You can actually write your own selectors to extend the Model Grid or test your XPath expressions on your model before adding them to an aspect. To do so, right-click in the Model Grid and select Selector Chooser. In the new dialog, there's an Add New button which allows you to add your own custom query.


Shared Features of API Classes

All concept classes (such as Project, Entity, Method, Rule, etc.) derive from the Node class. This is a key points since the Node class implements a set of functionalities which are then common to all those concepts such as:

Likewise, all collections in the API (e.g. EntityCollection, EnumerationCollection, ProducerCollection, etc.) derive from the .NET BindingList<T> class, which provides the AddNew and ListChanged events. As a consequence, aspects can subscribe to those events to be notified of changes on those collections.


Using the API

Check-out the Custom Aspects section to see how to write aspects using the API.

Likewise, CodeFluent Entities provides Built-in Aspects (in the XML) which can view to see they're using the API.

See Also