ASP. NET MVC: сопоставление сущностей для просмотра модели - PullRequest
2 голосов
/ 16 февраля 2010

Я пытаюсь очистить свои методы действия в проекте ASP.NET MVC, используя модели представлений. В настоящее время модели моего представления содержат объекты, которые могут иметь отношения с другими объектами. Например, класс ContactViewModel может иметь контакт, который может иметь адрес, оба из которых являются отдельными объектами. Чтобы запросить список объектов Contact, я мог бы сделать что-то вроде следующего.

IList<Contact> contacts;

using (IContactRepository repository = new ContactRepository())
{
    contacts = repository.Fetch().ToList();
}

EditContactViewModel vm = new EditContactViewModel(contacts);

return View(vm);

Этот метод вызывает несколько проблем. Например, хранилище запрашивается в операторе using. К тому времени, когда представление рендерится, контекст вышел из области видимости, что делает невозможным для представления запросить адрес, связанный с контактом. Я мог бы включить нетерпеливую загрузку, но я бы не хотел. Кроме того, мне не нравится, что модель сущностей кровоточила в моем представлении (мне кажется, что моему представлению плохо знать отношения между Контактом и Адресом, но не стесняйтесь не соглашаться со мной).

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

Какая техника предпочтительна для преодоления моих проблем?

Ответы [ 2 ]

3 голосов
/ 16 февраля 2010

Automapper будет работать для вашего случая. У вас есть объектный граф, у вещи есть еще несколько вещей, с которыми Automapper отлично справляется.

1 голос
/ 16 февраля 2010

Принимая эти проблемы в порядок ...

Во-первых, если вас беспокоит оператор using и репозиторий (я не знаю, является ли он LINQ-to-SQL или LINQ-to-Entities, но это не имеет значения), что бы я порекомендовал вам сделать это реализовать IDisposable на вашем контроллере, а затем сохранить хранилище в поле на модели или в контроллере или где-нибудь, где у вас есть доступ к нему в представлении (если вам это нужно, если модель знает об этом, в то время как модель объект "живой", тогда вам просто нужно сохранить его на всю жизнь контроллера).

Затем, когда запрос завершен, вызывается метод Dispose на вашем контроллере, и вы можете избавиться от хранилища там.

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

protected T AddDisposable<T>(T disposable) where T : class, IDisposable
{
    // Error checking.
    if (disposable == null) throw new ArgumentNullException("disposable");

    // Add to list
    ...
}

По сути, он позволяет хранить реализации IDisposable, затем в реализации IDisposable контроллера он выполняет итерацию по списку, избавляясь от всего.

Что касается раскрытия адреса в модели сущностей, лично я не рассматриваю это как проблему кровотечения. Адрес является частью состава контакта (IMO), поэтому было бы неправильно, если бы не имел его там.

Однако я не согласен, если вы этого не хотите, потому что вы хотите сосредоточиться на одном типе на одном контроллере за раз, и т. Д., И т. Д.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...