Entities File Settings

Entities

A list of database entities in your project. These entities are added as dbsets to your database context, so they translate 1:1 to tables in your database. With that said, if you want to create an aggregate, you can scaffold out an entity and update it accordingly to reflect that aggregate yourself (e.g. remove the db set).

Entity Properties

TableName is required if you want to set a schema

Properties

A list of properties that can be assigned to an entity.

Features

GetRecord, GetList, DeleteRecord, UpdateRecord, PatchRecord, AddRecord, and AddListByFk are all standard CRUD features along with their endpoints and associated tests.

ℹ DTOs, validators, profiles and functional test routes associated to all features will be added regardless of whether or not a given feature was added. This is due to the complexity of all the minute management around handling these so dynamically. Feel free to delete whatever you're not using.

AddListByFk Feature

The AddListByFk will let you add a list or batch of records using a foreign key. For example, you can add a list of ingredients for a recipe, based on the id of a recipe.

Ad Hoc Features

You can also add ad hoc skeletons with the AdHoc type. For AdHoc features, there's a bit more that needs to be done. In addition to Type above, you'll want to provide the below:

You can also add any of the above features after the fact using the add:feature command.

Keys

There are a couple of important pieces of information to know about settings keys for scaffolding:

1. As v0.12+, you do not need to add a primary key property to your entities as they will automatically be inherited from the BaseEntity.
2. Foreign keys can be set as shown in the examples below, but note that, in many cases, these will break some of your tests. You will likely need to update your tests fakers and
3. The 'Many' side of a foreign key will not be added to DTOs with scaffolding and will need to be added manually if you want to use it there. The 'Id' of a 'One' relationship will be added though.

Updating Tests That Use Foreign Keys to Green

This is the most noteworthy of the items above and will require the most manual intervention. Scaffolding here is tricky due to the variety of situations that can arise, so they need to be resolved manually. Here are a few tricks that may help:

1. Update your fakers. Autofaker will, by default, try and scaffold out your child or parent objects which can break your tests. Depending on your situation, you may need to set the foreign key to a particular value. Here are a couple rules that you could add:

   // you could create an empty list so that your tests don't have to accommodate the default of 3. only add them if you need them for a test
   RuleFor(s => s.Organizations, _ => new List<Organization>());
   
   // if you have a single foreign key, you may want to set the object and/or the id to null
   RuleFor(r => r.RecipeId, _ => null);
   RuleFor(r => r.Recipe, _ => null);
   
   // in some cases, your object may not make sense in your domain without having the object, so could generate a fake for it using your designated faker that has its own rules.
   RuleFor(i => i.Recipe, _ => new FakeRecipe().Generate()); 

2. Update the Arrange in your tests.

   For example, this could mean inserting a parent object into the database that can be assigned to the child to prevent a foreign key conflict.

   [Test]
   public async Task can_add_new_ingredient_to_db()
   {
       // Arrange
       var fakeRecipeOne = new FakeRecipe { }.Generate();
       await InsertAsync(fakeRecipeOne);
       
       var fakeIngredientOne = new FakeIngredientForCreationDto { }.Generate();
       fakeIngredientOne.RecipeId = fakeRecipeOne.Id;
   
       // Act
       var command = new AddIngredient.AddIngredientCommand(fakeIngredientOne);
       var ingredientReturned = await SendAsync(command);
       var ingredientCreated = await ExecuteDbContextAsync(db => db.Ingredients.SingleOrDefaultAsync());
   
       // Assert
       ingredientReturned.Should().BeEquivalentTo(fakeIngredientOne, options =>
           options.ExcludingMissingMembers());
       ingredientCreated.Should().BeEquivalentTo(fakeIngredientOne, options =>
           options.ExcludingMissingMembers());
   }

   Or making sure that you don't try and insert a user id that isn't in the db.

   [Test]
   public async Task can_update_existing_ingredient_in_db()
   {
       // Arrange
       var fakeIngredientOne = new FakeIngredient { }.Generate();
       await InsertAsync(fakeIngredientOne);
       
       var updatedIngredientDto = new FakeIngredientForUpdateDto { }.Generate();
       updatedIngredientDto.UserId = fakeIngredientOne.User.Id;
   
       var ingredient = await ExecuteDbContextAsync(db => db.Ingredients.SingleOrDefaultAsync());
       var id = ingredient.Id;
   
       // Act
       var command = new UpdateIngredient.UpdateIngredientCommand(id, updatedIngredientDto);
       await SendAsync(command);
       var updatedIngredient = await ExecuteDbContextAsync(db => db.Ingredients.Where(u => u.Id == id).SingleOrDefaultAsync());
   
       // Assert
       updatedIngredient.Should().BeEquivalentTo(updatedIngredientDto, options =>
           options.ExcludingMissingMembers());
   }

Policies Properties

Entity Example

This example would create a supplier entity with several properties. Note:

• The SupplierId is marked as a primary key
• We have normal and nullable primitives in the Type option
• We have marked the properties as sortable and filterable
• We have given a default value for IsVip
• We are adding all the available features except for PatchRecord. We're also adding an AdHoc feature for use for batch adding suppliers.

Entities:
  - Name: Supplier
    Features:
    - Type: AddRecord
    - Type: GetRecord
    - Type: GetList
    - Type: UpdateRecord
    - Type: DeleteRecord
    - Type: AddListByFk
      BatchPropertyName: OrganizationId
      BatchPropertyType: Guid
      ParentEntity: Organization
      BatchPropertyDbSetName: Organizations
    - Type: AdHoc
      Name: MySpecialLookup
      Command: MySpecialLookupQuery
      EntityPlural: Suppliers
    Properties:
      - Name: Name
        Type: string
        CanFilter: true
        CanSort: true
      - Name: EmployeeCount
        Type: int?
        CanFilter: true
        CanSort: true
      - Name: CreationDate
        Type: datetime?
        CanFilter: true
        CanSort: true
      - Name: SupplierType
        Type: int?
        CanFilter: true
        CanSort: true
      - Name: IsVip
        Type: bool?
        CanFilter: true
        CanSort: true
        DefaultValue: false
      - Name: OrganizationId
        Type: Guid?
        ForeignEntityName: Organization

Example With Foreign Key

Foreign keys can be added in any of the below ways. At a high level, you'll notice there is a syntax for adding the 1 relationship type and the many relationship type.

One to One Relationships

Entities:
  - Name: User
    Properties:
    - Name: Name
      Type: string
    - Name: UserProfileId
      Type: Guid?
      ForeignEntityName: UserProfile
      ForeignEntityPlural: UserProfiles
  - Name: UserProfile
    Properties:
    - Name: Name
      Type: string
    - Name: UserId
      Type: Guid
      ForeignEntityName: User
      ForeignEntityPlural: Users

One to Many Relationships

Here, we have a Blog with many Posts. The Type of the foreign id doesn't have to be a Guid, but is in this example. Additionally, the many Posts can be any collection that works for a normal .NET relationship, in this example, an ICollection. It does also need a ForeignEntityPlural to allow for a proper using statement.

Entities:
  - Name: Post
    Properties:
    - Name: Name
      Type: string
    - Name: BlogId
      Type: Guid?
      ForeignEntityName: Blog
      ForeignEntityPlural: Blogs
  - Name: Blog
    Properties:
    - Name: Name
      Type: string
    - Name: Posts
      Type: ICollection<Post>
      ForeignEntityPlural: Posts

Many to Many Relationships

Here, we have many Books that can also have many Categories. Like the One to Many relationship, the Type can be any collection that works for a normal .NET relationship. As with one to many, they need a ForeignEntityPlural to allow for a proper using statement.

Entities:
  - Name: Book
    Properties:
    - Name: Name
      Type: string
    - Name: Categories
      Type: ICollection<Category>
      ForeignEntityPlural: Categories
  - Name: Category
    Properties:
    - Name: Name
      Type: string
    - Name: Books
      Type: ICollection<Book>
      ForeignEntityPlural: Books

Composite Keys

For the time being, composite keys can not be created using Craftsman commands. With that said, you are more than welcome to scaffold out an entity with one of the keys and then modify the generated entity, repository, tests, etc. to accommodate that composite key.

Policies

Something like the below would add policies to your features.

  Entities:
  - Name: Recipe
    Features:
    - Type: GetList
      Policies:
      - Name: RecipesReadOnly
        PolicyType: scope
        PolicyValue: recipemanagement.readonly
    - Type: GetRecord
      Policies:
      - Name: RecipesReadOnly
        PolicyType: scope
        PolicyValue: recipemanagement.readonly
    - Type: AddRecord
      Policies:
      - Name: RecipesReadOnly
        PolicyType: scope
        PolicyValue: recipemanagement.readonly
    - Type: UpdateRecord
      Policies:
      - Name: RecipesReadOnly
        PolicyType: scope
        PolicyValue: recipemanagement.readonly
    - Type: DeleteRecord
      Policies:
      - Name: RecipesFullAccess
        PolicyType: scope
        PolicyValue: recipemanagement.fullaccess