Custom fields has been around since ado .net and it was a simple affair in those days to add custom fields at runtime to a table one would simply do the following. At runtime and it was added to the grid cause developers where lazy doing a select * from tableName
ALTER TABLE table_name ADD column_name datatype --add column
ALTER TABLE table_name DROP COLUMN column_name --delete column
However in Entity frame work it is more complicated than it needs to be and forces the development team to use a table to describe these extra fields.
In ef core I would see this working like an extension method at run time in that you would have the following
_context.TableName.AddRunTimeColumn("ExampleField1",string,40);
This would then make the column avaialble to the table that user adds to it would be ideal then if we had a collection of custom fields for example one could then loop over
foreach (var field in _context.TableName.CustomFields)
{
/display the fields as what ever control here
}
If for example a data grid it should automatically pull in the custom fields which the option of accessing as such.
ClassName.CustomField.ExampleField1
You should still be able to access the field as such
_context.TableName.where(x=>x.ExampleField1 = "Test"); it should stick to the rules of the data types declared above.
The custom fields object should honour any existing data annotations
Are these custom fields regular database columns? If so, migrations can be used to add or remove database columns, but EF indeed doesn't provide an easy API for doing this at runtime - and for good reason. Your database schema typically isn't something that should be modified at runtime, e.g. because multiple instances of your programs may cause severe interference with one another. In addition, EF itself has a model of the database that is not expected to change all the time.
If you can provide more details on why think you need this, that would be helpful.
@roji Plenty of crm systems world wide including Business One sap offer custom fields This would be more for the back end and then produce the form or fields at first launch or via a button.
@davidbuckleyni as I asked above, the question is whether these custom fields are backed by actual database columns. In many cases, when a "dynamic" schema is required (i.e. the ability to add/remove fields), the fields aren't backed by columns: you can easily have a CustomFields table with Name and Value columns, and have a foreign key relationship to any table that needs to have custom fields. Saving a new field simply means inserting a row into this table with a new Name.
as I asked above, the question is whether these custom fields are backed by actual database columns
Repsonse Yes is the answer,
Your Repsonse I get what you are saying but when you want to query the custom field values in a ef where clause it becomes more tricky
@davidbuckleyni I discussed this with the rest of the team. EF Core Migrations can be used to evolve a database schema, including adding columns like this. However, I would caution against doing this dynamically at runtime for anything other than a database accessed by a single user at a time.