MXMS

What is MXMS

An example implementation using the MXMS framework

The MXMS framework enables rapid development of business software solutions by using a structured class entity model in which the database / SQL is maintained and updated by the framework and the UI is built.

MXMS enables rapid development of API's which exposes certain fuctionality of the entity model in a JsonRPC, REST or a custom format.

Custom scheduled tasks can be created for background processes to execute to create data synchronisation tasks or other custom workflows.

.NET Core

MXMS uses ASP .NET Core as the development platform and is written in C#. The core libraries are written in .NET Standard 2.0 for maximum portability.

Model driven development

At it's core a MXMS implementation expects a model definition which is used to generate the application and it's functionality.

A model is a collection of classes which contains properties annotated with attributes which provides context to the property and methods which provides functionality to the implementation.

Configuration

MXMS being injected into the ASP.NET pipeline

MXMS has various ways of changing the application configuration. There is a json file which contains basic configuration which changes from instance to instance. The main way to configure the application is through strongly types configuration classes using the options pattern in the startup.cs. The strongly typed configuration can be further filled by creating a module. A module can be re-used to provide certain functionality to implementations. The application configuration can be accessed using the application class

Application configuration

MXMS is injected into the ASP.NET Core pipeline during startup of the .NET Core application. MXMS provides injection classes to enable the MXMS application within the ASP.NET Core implementation. Additional ad-hoc configuration can be passed during the initial startup of the application. MXMS uses a strongly types class model to confige the application furing startup.

Modules

For a modular approach modules can be created which can be injected into the application. A module is a class which injects configuration options to the application. This module can be re-used in various implementations.

mxmsSettings.json

MXMS uses a json file called mxmsSettings.json to configure specific items between instances. Each instance of the application can have it's own mxmsSettings.config. The file is using the json format.

The configuration consists of the global mailserver settings which are used to send mails and the connection string which provides storage for the ORM mapper. Additionally MXMS registers when which scheduled process was last run. It uses this information to determine which processes needs executing.

If a mxmsSettings.json file is not present during application startup an empty configuration file is created which can be edited as required.

log4net.config

MXMS uses log4net to provide logging functionality. This module is configured using the log4net.config file located in the workingdirectory of the application.

Data storage

MXMS uses NHibernate as it's Object Relational Mapper. MXMS feeds NHibernate custom configuration data based on the model which is implemented.

Dialects

Editing an uploaded image with the image editor in MXMS

File storage

MXMS uses a so called workingdirectory in which MXMS requires full access. This folder is used to store various files which are either generated, loaded by certain modules or manually uploaded by users using the application.

Uploaded media

Users are able to upload and edit media using the entityimage class. Files uploaded are stored in the <WORKINGDIRECTORY>/media/ folder.

Mail templates

The mail sender stores it's templates in the <WORKINGDIRECTORY>/templates/ folder

User interface

MXMS uses Vue as it's javascript client framework to render it's javascript GUI.

Background processes

TODO add background process info

Security

Various concepts are in place to either grant or deny users specific access to the application.

Rights by definition type

The following permissions are available for each type.

Rights by definition type

Type	Permissions
Entities	Create, Read, Update and Delete
Properties	Create, Read and Update
Methods	Execute

Access modifiers

The maximum allowed permissions for a property or method is based on the access modifiers of the property. Only public access modifiers can be accessed by users. This is based on the getter (read access) and the setter (write access).

public virtual string ExampleProperty
{
    get; 
    protected set;
}

In the example above the property maximum availability is read access.

Attributes

To further limit access if access modifiers are not feasible is by using the availability attribute. This attribute defines the maximum available permissions for a property. The options are None, Writeonly and Readonly.

[Availability(Availability.ReadOnly)]
public virtual string Name
{
    get; set;
}

In the example above the property maximum availability is read access.

Roles

A role defines which classes, properties and methods the user has access to. A user can be added in multiple roles and the cummultative permission set of classes, properties and methods will be the users final access profile. Roles are registered and added to the application using modules.

public class ExampleAccessProfile : CodedAccessProfile
{
    protected override void Configure()
    {

        Set<Class1>()
            .AllowAllRead();

        Set<Class2>()
            .AllowAllCreate()
            .AllowAllUpdate()
            .AllowDelete();

        Set<Class2>()
            .AllowAllUpdate();
    }
}

In the example above the role has read access to Class1, has full control access to Class2 and update access to Class3. Read access is automatically granted when providing update access.

Claims

Claims is another form to limit access to properties or methods. By adding a claim the entity's state determines if the policy is added. Claims are registered and added to the application using modules.

public class ExampleClaim : Claim<CustomEntity>
{
    protected override bool CanApply(CustomEntity entity)
    {
        return entity.BooleanCheck;
    }

    protected override void Set(CodedAccessPolicyBuilder<CustomEntity> policy)
    {
        policy.DenyMethod(i => i.MyMethod());
    }
}

In the above example the method MyMethod() is denied access if the BooleanCheck value is true.

Filters

TODO add filter information

API development

TODO add APIs info.