Создание большой формы с несколькими раскрывающимися списками и текстовыми полями в ASP.NET MVC - PullRequest
Новая
       29

Создание большой формы с несколькими раскрывающимися списками и текстовыми полями в ASP.NET MVC

2 голосов
/ 01 марта 2010

В моем продолжающемся путешествии по ASP.NET MVC я сейчас нахожусь в точке, где мне нужно визуализировать форму редактирования / создания для сущности.

Моя сущность состоит из перечислений и нескольких других моделей, созданных в хранилище через LINQtoSQL.

Сейчас я борюсь с тем, чтобы найти достойный способ визуализации форм редактирования / создания, которые будут содержать несколько выпадающих списков и несколько текстовых полей. Я понимаю, что это, возможно, не самый удобный подход, но именно этим я сейчас и займусь:).

У меня есть уровень хранилища и бизнес-уровень. Контроллеры взаимодействуют с сервисным уровнем.

Лучше ли просто создать модель вида, подобную этой? 

public class EventFormViewModel
{
    IEventService _eventService;

    public IEvent Event { get; private set; }

    public IEnumerable<EventCampaign> Campaigns { get; private set; }
    public IEnumerable<SelectListItem> Statuses { get; private set; }
    // Other tables/dropdowns go here

    // Constructor
    public EventFormViewModel(IEventService eventService, IEvent ev)
    {
        _eventService = eventService;
        Event = ev;

        // Initialize Collections
        Campaigns = eventService.getCampaigns().ToSelectList(); //extn method maybe?
        Statuses = eventService.getStatus().ToSelectList();  /extn for each table type?
    }

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

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

Последняя часть моего вопроса: возможно ли для метода расширения ToSelectList () написать один метод для каждой таблицы и использовать его в общем случае, даже если некоторые таблицы имеют разные столбцы («Id» и «Name» по сравнению с «) Id "и" CampaignName ").

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

Ответы [ 2 ]

1 голос
/ 01 марта 2010

Я бы не стал предоставлять IEventService для моего объекта модели представления. Я предпочитаю думать об объекте модели представления как о тупом объекте передачи данных. Я бы позволил контроллеру позаботиться о том, чтобы запросить данные у IEventService и передать их в модель представления.

Я бы по существу вытащил все данные вернуться из базы данных на несколько разные таблицы и их преобразование к IEnumerable

Не понимаю, почему это было бы неэффективно? Вы, очевидно, не должны извлекать все данные из таблиц. Выполните фильтрацию и объединение, которые вам нужно сделать в базе данных, как обычно. Поместите результат в модель представления.

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

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

Худшее, что вы могли бы сделать, - это пройти уровень обслуживания только тогда, когда вы чувствуете, что в этом есть необходимость, и сразу перейти в хранилище, когда уровень обслуживания не будет предоставлять никакой дополнительной логики. Что бы вы ни делали, будьте последовательны (что почти всегда означает: проходите уровень обслуживания, даже если ваше приложение простое. Оно не останется простым).

0 голосов
/ 01 марта 2010

Я бы сказал, что если вы думаете о «пропуске» слоя, вы на самом деле не готовы использовать MVC. Весь смысл уровней, даже если они тонкие, заключается в том, чтобы облегчить модульное тестирование и попытаться обеспечить разделение задач.

Что касается универсальных методов, есть ли какая-то причина, по которой вы можете просто использовать объекты OOB и затем расширять их (с помощью методов расширения), когда они не удовлетворяют вашим потребностям?

...