-
Notifications
You must be signed in to change notification settings - Fork 5
architecture overview
The CDP4-COMET Web Services have been designed to provide the performance that is required by users. At the same time the design of the CDP4-COMET Web Services is based on SOLID principles.
Similar to the CDP4-COMET-SDK and CDP4-COMET-IME, the CDP4-COMET development team makes use of code-generation for the development of the CDP4-COMET WebServices. This speeds up the development of the application and makes sure the applicaiton is compliant with ECSS-E-TM-10-25 Annex A and the CDP4-COMET Data Model.
The classess that are code generated are generated as partial classess, which allows hand-coding algorithms in other code files that do not lend themselves to code-generation.
Dependeny injection is at the heart of the application, where we rely on Autofac to perform (primarily) property injection.
The CDP4-COMET Web Services soltuion contains the following projects:
- CometOrm
- CDP4Authentication
- CDP4DatabaseAuthentication
- CometServer
- VersionFileCreator
The CometOrm project contains the classess and business logic that perform all CRUD operations on the CDP4-COMET Database.
For each class in the CDP4-COMET Data Model a Dao class is generated. The Dao classess follow the inheritance of the classess in the CDP4-COMET Data Model. The generated Dao classes can be found in the AutoGenDao folder.
Each generated Dao class is responsible for performing the Read, Write, Update and Delete operation, where the Read operations are only available for concrete classes and not for abstract classes. The Doa classess map to tables in the CDP4-COMET Database and basicaly map CDP4-COMET DTO's to tables and link-tables in the database.
The database design is such that for each class in the CDP4-COMET Data Model a table exists that is responsible for the persistence of the value and reference properties. This includes tables for abstract classes. Hence, for each write, update and delete operation the write, update and delete operation of the base class is invoked as well, concluding at the ThingDao class.
The ThingDao class, which represents the Thing class from the COMET Data Model, itself derives from the BaseDao class. The BaseDao class provides virtual methods that allow to inject code that is exexuted before or after any Update, Delete and Write operation. These methods can be implemented (override) with hand-written code in the Dao\Supplemental folder by creating a partial class file that corresponds to the class that needs an implementation of any of the before\after methods.
The structure of the ORM Dao classess is further explained here.
The CometOrm also provides the capability to migrate data between different versions of the CDP4-COMET. The migration engine documenation can be found here.
The CometServer project contains the application code and business logic to implement ECSS-E-TM-10-25 Annex C and the CDP4-COMET extensions. The CometServer is developed using ASP.NET Core 8.0 and a lightweight routing library called Carter.
The CometAuthentication project provides the infrastructure for authentication plugins such as the database authenticator and the LDAP authenticator plugin.
The CometDatabaseAuthentication project provides the database authenticator plugin that supports authentication of users agains the CDP4-COMET database.
The VersionFileCreator is a commandline application that generates the VERSION file that contains the name and version number of the CDP4-COMET libraries and components.
copyright @ Starion Group S.A.