highlights of the carmel api entity framework core usage

[adriatic]

carmel-api database is created using the "code-first" approach using classes in models folder as definition of entities.

The database is defined in the config.json file as the local instance of MSSQLLocalDB. This choice supports easy deployment to the production instance in the cloud. I tried to do this using Azure and we will likely have to do it in EWS/ECS for "business reasons" 😄 .

While the process of database creation appears to use the concept of migrations, for practical reasons I decided not to go beyond the first step in this process. In other words, when the carmel database has to be updated, it should repeat the whole database creation process, starting with updating the classes in the models folder. This allows the database maintenance with very minimal knowledge of "real" database administration.

carmel uses the standard repository pattern approach (note that this referenced article is a bit behind as it uses Visual Studio 2015). This further uses ef core context - as implemented in CatalogContext class. Note that this class defines the database as well as I had some difficulties using the previously mentioned config.json approach.

[adriatic]

At this time I do not remember whether I tested every implemented API endpoint - and I do know that the existing API set is incomplete. More has to be added to implement database writes and features that we discussed today - support for approving and merging data created by the Tag Editor for example.

[adriatic]

why are we using mapper in carmel-API code

mapper is "declared" in the carmel.csproj file and set up in the project.cs

Its role is to manage the mappings between the model's database view (which has data that should not be presented to the user - ID is a good example of that) and the model's user view.