Hi!

Нужен совет как лучше реализовать следующий функционал.
Есть таблица в БД tblContact с полями контакта (ID, FirstName, LastName, Phone etc).
Таблица мапится на сущность Contact.

Теперь заказчик хочет, чтоб у пользователя была возможность самому в программе создавать дополнительные любые поля у контакта.
Например Birthday, Phone2, Email3 и т.д.
Имя и тип нового поля задаёт пользователь.

В принципе такой функционал я видел в нескольких CRM.

Как это лучше реализовать? Как такие поля лучше хранить в БД и как их мапить с помощью EF?

Спасибо.

Здравствуйте, Аноним, Вы писали:

А>Hi!

А>Нужен совет как лучше реализовать следующий функционал.
А>Есть таблица в БД tblContact с полями контакта (ID, FirstName, LastName, Phone etc).
А>Таблица мапится на сущность Contact.

А>Теперь заказчик хочет, чтоб у пользователя была возможность самому в программе создавать дополнительные любые поля у контакта.
А>Например Birthday, Phone2, Email3 и т.д.
А>Имя и тип нового поля задаёт пользователь.

А>В принципе такой функционал я видел в нескольких CRM.

А>Как это лучше реализовать? Как такие поля лучше хранить в БД и как их мапить с помощью EF?

А>Спасибо.

Можно так:

 class Field
  {
    public strang Name{get;set;}

    public strina Value{get;set;}

    public FieldType Type{get;set;}
  }

 enum FieldType
{
  Email,
  
  Phone
}

Можно еще сделать иерархию классов Field. По разному можно, зависит от задачи.

Здравствуйте, Аноним, Вы писали:

А>Можно так:

А>

А> class Field
А>  {
А>    public strang Name{get;set;}

А>    public strina Value{get;set;}

А>    public FieldType Type{get;set;}
А>  }

А> enum FieldType
А>{
А>  Email,
  
А>  Phone
А>}
А>

А>Можно еще сделать иерархию классов Field. По разному можно, зависит от задачи.

Спасибо за ответ

У меня куча вопросов

То есть в БД будет 1 таблица с полями Name, Value, Type, ContactID?
Value — всегда string? — а как быть с типизацией (DateTime, int, bool)?

Как это будет связано с сущностью Contact? — у Contact будет List<Field> ?

У нас Contact часто отображается в гридах — как тогда вывести эти пользовательские колонки в грид? — как быть с их типом, если они все string грид не сможет их ни фильтровать правильно ни сортировать...

А>Спасибо за ответ

А>У меня куча вопросов

А>То есть в БД будет 1 таблица с полями Name, Value, Type, ContactID?
Да
А>Value — всегда string? — а как быть с типизацией (DateTime, int, bool)?
Можно сделать иерархию, можно в Value использовать object а не string.
А>Как это будет связано с сущностью Contact? — у Contact будет List<Field> ?
Да
А>У нас Contact часто отображается в гридах — как тогда вывести эти пользовательские колонки в грид? — как быть с их типом, если они все string грид не сможет их ни фильтровать правильно ни сортировать...
Сортировать по enum FieldType. Вообще в гриде я думаю следует отображать тип поля, что бы пользователь знал какие данные можно вводить, ведь email != phone.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:


А>Value — всегда string? — а как быть с типизацией (DateTime, int, bool)?
В БД — очевидно, да. В приложении всегда можно делать конвертацию когда надо.

А>У нас Contact часто отображается в гридах — как тогда вывести эти пользовательские колонки в грид? — как быть с их типом, если они все string грид не сможет их ни фильтровать правильно ни сортировать...

При добавлении колонки в грид обфчно можно указать её тип.

Если хочется использовать databinding, то можно соорудить что-то в таком духе.
Гриду в качестве коллекции можно подсовывать ITypedList, который через GetItemProperties возвращает описания свойств элемента коллекции в виде PropertyDescriptor. Через PropertyDescriptor в свою очередь можно реализовать произвольные PropertyType, GetValue, SetValue и прочие полезности.

Здравствуйте, Аноним, Вы писали:


А>>У нас Contact часто отображается в гридах — как тогда вывести эти пользовательские колонки в грид? — как быть с их типом, если они все string грид не сможет их ни фильтровать правильно ни сортировать...
А>При добавлении колонки в грид обфчно можно указать её тип.

Только при этом нужно ещё и чтоб и данные в ячейках грида имели тип колонки а не стринг. Т.е. надо когда-то их конвертировать...

А>Если хочется использовать databinding, то можно соорудить что-то в таком духе.
А>Гриду в качестве коллекции можно подсовывать ITypedList, который через GetItemProperties возвращает описания свойств элемента коллекции в виде PropertyDescriptor. Через PropertyDescriptor в свою очередь можно реализовать произвольные PropertyType, GetValue, SetValue и прочие полезности.

Интересная ссылка, не знал такого, спасибо.