Свойство MVC4-модели должно быть списком или ICollection другого класса.

Question

Я делаю тип тестового приложения, использующего сначала код Entity Framework. У меня есть базовый класс Question, из которого MultipleChoiceQuestion, EssayQuestion, и другие типы вопросов спускаются. MultipleChoiceQuestions, очевидно, имеют несколько ответов, из которых должен выбрать контролер. Мой вопрос связан с выбором лучшего способа сохранить их в экземпляре вопроса.

я мог бы объявить класс со списком строк, чтобы держать ответы, например, так:

public class MulitpleChoiceQuestion : Question 
{ 
    private List<String> Answers = new List<String>(); 
    // other declarations, etc. 
} 

Вместо этого я мог бы объявить еще один класс с именем Answers, и пусть мои Question классов используют набор ответов.

public class Answer 
{ 
    public int AnswerID { get; set; } 
    public String AnswerText { get; set; } 

    public virtual Question Question { get; set; } 
} 

И тогда в моем вопросе подклассов (а не только MultipleChoiceQuestions)

public class MulitpleChoiceQuestion : Question 
{ 
    public virtual ICollection<Answer> Answers { get; set; } 
    // other declarations, etc. 
} 

Есть ли лучший способ, чем любой из них? Если нет, то какая из них лучше и почему? Мне сложно найти что-то подробное в Интернете, и большинство книг тоже не идут так глубоко. Заранее благодарим за любые рекомендации.

Answer 1

Я спросил .NET, другу, профессор моего этот вопрос, и это его ответ:

Оба ваших декларации призывают коллекции. Список - это типизированная коллекция , а ICollection - нетипизированная. Типичная коллекция (список) имеет два преимущества по сравнению с нетипизированными коллекциями. Тип каждой коллекции проверяется во время компиляции и, таким образом, предотвращает ошибки времени выполнения. Во-вторых, они уменьшают количество литья, которое необходимо при извлечении объектов .

я впервые реализовал решение ICollection, и это было неуклюжим в нескольких местах (например, Initializer данных семян):

var mcQuestions = new List<MultipleChoiceQuestion> 
    { 
     new MultipleChoiceQuestion { 
      QuestionText = "What is the value returned by the expression (true == false? 'yes': 'no')?", 
      Answers = new List<Answer> { new Answer { AnswerText="true"}, new Answer { AnswerText = "false"}, new Answer { AnswerText = "can't be determined"}, new Answer {AnswerText = "45"}, new Answer { AnswerText = "blue"}} 
     }, 
     new MultipleChoiceQuestion { 
      QuestionText = "C-Sharp responds to a global variable declaration by:", 
      Answers = new List<Answer> { new Answer { AnswerText="throwing a compile error"}, new Answer { AnswerText = "throwing a runtime error"}, new Answer { AnswerText = "Throwing an Invalid operator warning"}, new Answer {AnswerText = "Printing a warning to the console"}, new Answer { AnswerText = "doing nothing; global variables are legal"}} 
     } 
    }; 
    mcQuestions.ForEach(mcq => context.MultipleChoiceQuestions.Add(mcq)); 
    context.SaveChanges(); 

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

Answer 2

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

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

В общем, я бы сказал: если у вас есть два способа решения проблемы, то выбрать тот, который делает ваш код самым легким для чтения/понимания при просмотре кода.