Вложенные классы ViewModel в asp.net MVC - PullRequest
1 голос
/ 21 февраля 2012

У меня есть четыре класса домена уровня модели MVC.

namespace MvcMobile.Models.BusinessObject
{
public class Speaker
{
    public int SpeakerID { get; set; }
    public string SpeakerName { get; set; }
}
public class Tag
{
    public int TagID { get; set; }
    public string TagName { get; set; }
}
public class Seminar
{
    public string Seminar_Code { get; set; }
    public string Title { get; set; }
    public string Description { get; set; }
    public string Room { get; set; }        
}
public class Seminar_Detail
{
    public string Seminar_Code { get; set; }
    public int SpeakerID { get; set; }
    public int TagID { get; set; }
    public string DateAndTime { get; set; } 
}
}

Я хотел бы выполнить операцию CRUD с использованием этих классов.Поэтому я создаю два VeiwModel класса.

namespace MvcMobile.ViewModel
{
public class Seminar_Root_ViewModel
{
    public Seminar_Subsidiary_ViewModel Seminars { get; set; }
    public List<Speaker> Speakers { get; set; }
    public List<Tag> Tags { get; set; }
}
public class Seminar_Subsidiary_ViewModel
{
    public Seminar Seminar { get; set; }
    public List<Seminar_Detail> Seminar_Detail { get; set; }
}
}

Для Controller layer я считаю, что буду использовать Seminar_Root_ViewModel для выполнения всех операций CRUD.

Что бы я хотелСпросите, это правильный или правильный путь?
Если у вас есть более элегантный способ сделать model layer and ViewModel layer, пожалуйста, дайте мне получить предложение.

Любое предложение будет оценено.

[обновлено]

Давайте предположим, что я делаю дизайн формы master-Detail.

Speaker and Tag - это просто справочные таблицы для выпадающего списка или некоторых подобных элементов управления.
Seminarэто основные данные, а Seminar_Detail будет данными таблицы элементов.
Итак, что касается этого сценария, все эти классы необходимы для этой программы.

Пожалуйста, дайте мне знать, если я ошибаюсь.

1 Ответ

0 голосов
/ 23 февраля 2012

Единственное, что я вижу, это то, что если вы не собираетесь повторно использовать Seminar_Subsidiary_ViewModel модель представления, вы можете пропустить ее.

Если вам понадобятся эти два свойства Seminar и Seminar_Detail в другом представлении или вызове ajax, вполне нормально иметь такое разделение.

Лично я не большой поклонник _ в имени класса, но это не имеет никакого отношения к вопросу.

...