Kros-sk / Kros.Libs

This repo contains Kros.Utils, Kros.Utils.MsAccess, Kros.KORM and Kros.KORM.MsAccess libraries.
MIT License
7 stars 13 forks source link

KORM - ideas and suggestions for new features #177

Open satano opened 5 years ago

satano commented 5 years ago

General info

Do not close this issue. This is a "meta issue". It is just for writing down any ideas and suggestions for KORM. Ideas here, once consulted, will be moved to separate issues.

Support for complex entities, whose properties are another objects

Now we only support one-to-one mapping of object's properties to data table columns. It is not sufficient. Often there are situations, where there is one table in database, but entity class does not have many primitive properties, but just some complex ones. For example invoice. In database it can be table with columns: Id, InvoiceNumber, SupplierName, SupplierAddress, PurchaserName, PurchaserAddress, but in code, it is represented by this classes:

public class ContractingParty
{
    public string Name { get; set; }
    public string Address { get; set; }
}

public class Invoice
{
    public int Id { get; set; }
    public string InvoiceNumber { get; set; }

    // Sub-properties are mapped to `SupplierName` and `SupplierAddress` columns.
    public ContractingParty Supplier { get; } = new ContractingParty();

    // Sub-properties are mapped to `PurchaserName` and `PurchaserAddress` columns.
    public ContractingParty Purchaser { get; } = new ContractingParty();
}

Simpler Delete of entities

Now, if we want to delete an entity, we can use direct SQL statement (ExecuteNonQuery), or DbSet. The disadvantage of ExecuteNonQuery is, that it does not have ane knowledge about entity type, so the SQL must be hand written. Disadvantage of DbSet is that we need to create an instance of the entity, just to have its ID. I'd like to have something which can be used without creating an entity instance:

_database.Delete<EntityType>(123)

Things to think about is where to implement this (IDbSet, IDatabase...). And it should at least support int and long primary keys (generic of <TEntity, TKey>?), but better any keys (even composite ones).

Value generators for columns

Now we have some support for generated primary keys. But we only support int (no long). It is achieved by Key attribute. It woul be better to have something like ValueGenerator attribute, which will generate value for column on INSERT. And it could be used for any column, not just primary key.

Timestamp column

This would be special column (for start marked with some attribute) of DateTime/DateTimeOffset type. Value for this column would be automatically set to current date and time on every INSERT or UPDATE.

Use ConnectionStrings section with named connection strings

We use our own setup of connection string in setting. We require ConnectionString section with ProviderName and ConnectionString subkeys. We could use default connection strings settings (as Entity Framework does it). The section name is ConnectionStrings and subkeys are name of connection strings. Provider can be integrated in connection string itself. When creating IDatabase, connection string name will be specified. If the name is not specified, default name DefaultConnection will be used.

Use different kind of configuration than attributes

Now some configuration is allowed only using attributes (Key, Alias). Something can be changed using custom ModelMapper. Maybe we can think about different kind of configuration instead of attributes.