EF Code First - как это моделировать?

Question

Сначала я работаю над веб-приложением (MVC) с использованием кода Entity Framework, и я пытаюсь понять, как его моделировать. Я мог бы добавить 15 значений bool в класс (бит в базе данных), но это похоже на жалкий способ сделать это. В настоящее время у меня есть объект клиента, который будет содержать объект для политик, показанных на изображении ниже.

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

public class customer{ 
    //some random properties like Id, Name, Owner, Etc. 
    //I could put 15 bools here for the policies in the image 
    //I could put a policy object here? 
} 

Answer 1

Вы могли бы взглянуть на ТРТ (таблица для каждого типа) для этого, посмотрите здесь http://blogs.microsoft.co.il/blogs/gilf/archive/2010/01/22/table-per-type-inheritance-in-entity-framework.aspx

Это будет означать, что вы могли бы иметь таблицу для каждого из этих различных концепций, которые расширяют базу Таблица. Бонус делать это так, так как позже вы можете добавить дополнительную информацию к определенному типу.

EG, клиент будет корневая таблица, а затем быть расширен с такими понятиями, как OriginalMedicareCustomer

Answer 2

Если вы хотите, чтобы нормализовать его, я рекомендую идти об этом так:

public class Customer { 
    // id, name, owner, etc 
    public virtual IList<CustomerPolicy> Policies { get; set; } 
} 

public class CustomerPolicy { 
    // id, name, etc 
    public bool ExistingPatient { get; set; } 
    public bool AgeInPatient { get; set; } 
    public bool NewPatient { get; set; } 
} 

, не зная больше о вашем приложении, я не могу сказать, но я предполагаю, что три логических значения для каждой политики являются взаимоисключающими? Если да, то я бы вместо того, чтобы сделать что-то вроде этого:

public enum PatientType { Existing, AgeIn, NewPatient }; 

public class CustomerPolicy { 
    // id, name, etc 
    public PatientType PatientType { get; set; } 
} 

Answer 3

Я не совсем уверен, что ваши требования в отношении данных, но я бы сохранить его простым и в таблице или два, что-то вроде этого ...

public class Customer 
{ 
    public int CustomerID { get; set; } 
    // or implement it via enum like below for policy type 
    public bool Existing { get; set; } 
    public bool AgeIn { get; set; } 
    public bool New{ get; set; } 
    // no 'virtual' means it's 'required', with virtual could be 'null' 
    public Policy Policy { get; set; } 
} 
public enum PolicyBits 
{ 
    None = 0x00, 
    ExistingOriginalMediCare = 0x01, 
    // ... 
    AgeInOriginalMediCare = 0x100, 
    // ... 
} 
public class Policy 
{ 
    public int PolicyID { get; set; } 
    public int PolicyTypeValue { get; set; } 
    [NotMapped] 
    public PolicyBits PolicyType 
    { 
     get { return (PolicyBits)PolicyTypeValue; } 
     set { PolicyTypeValue = (int)value; } 
    } 
} 

... enum поможет вам уменьшить число бит, но оно официально не поддерживается, будет из следующей версии и пока только в экспериментальных версиях VS 2011 и .NET 4.5 (как я помню).

но вы можете временно обойти его чем-то вроде ниже.

Что касается модели таблиц - я не уверен, как вы хотите «переключиться» между существующими, новыми или возрастными пользователями - или вы можете одновременно иметь как или все три и т. Д. Поскольку все это биты. Я думаю, что одно поле должно быть достаточно - и, возможно, поместить его в отдельную таблицу для разделения в основном - то есть, чтобы вы могли переопределить это, добавить новые вещи или ввести новые записи и т. д.

Answer 4

Вот дизайн, который является простым, самоописательным, масштабируемым, нормализованным и расширяемым. Вы можете добавлять дополнительные типы политик или типы пациентов без перекомпиляции системы. Вы не указали, какой механизм баз данных вы используете, поэтому, чтобы он работал на большинстве платформ баз данных, я бы предложил использовать TPC.

Пациент просто роль, которую человек (он же партии) играет в системе. У вас могут быть другие роли, такие как «врач», «сотрудник», «держатель политики» и т. Д., Каждый со своими собственными данными. Важно отметить, что роли временны, что означает, что одна роль может быть аннулирована, а человек выполняет другие роли в системе.

Если «Существующий», «AgeIn», «NewPatient» можно определить, просмотрев свойства Роли или Стороны, нет необходимости в PatientType. Я добавил его, потому что неясно, как определяются типы терпимости. У вас вполне может быть только свойство Patient, чтобы определить это.

Сторона представляет любое юридическое лицо. У сторон есть отношения, которые часто важны для бизнеса. Поэтому, когда «Сэм» (человек) приходит к «Доктору» (человеку, играющему роль), важно знать, что «политика» ее отца Боба (человека) будет оплачивать счет. Отсюда причина, по которой Человек отображается в другой таблице.

PolicyType определяет, какой тип политики действительно существует. В вашем случае у вас может быть 18 различных типов политик, например ExistingOriginalMediCare, AgeInOriginalMediCare и т. Д. Здесь вы можете хранить данные, которые влияют на «правила» вашей политики. Например, некоторые типы политик доступны только для людей, живущих в Калифорнии. В одной системе, в которой я работал, были тысячи типов политик, каждый из которых обладал сотнями свойств, которые приложения использовали для определения бизнес-правил. Это позволило бизнесу создавать новые типы политики и «правила» без перекомпиляции системы и всего, что от нее зависело.

Однако его можно упростить, выбирая наследование при сохранении тех же возможностей. Здесь мы предполагаем, что не будет никакой другой «роли», чем «пациент» и никакой другой «партии», чем «человек».

Тем не менее, это действительно зависит от того, будет ли данные быть повторно использованы в других приложениях и как временные данные и ассоциации на самом деле. Не стесняйтесь адаптироваться. Я часто ссылаться на эти книги при проектировании систем:

1. Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML
2. Enterprise Model Patterns: Describing the World (UML Version)
3. The Data Model Resource Book, Volume 3: Universal Patterns for Data Modeling

Они коренным образом изменили мой взгляд на "данные".