Как проверить элемент с привязкой к модели, не нарушая DRY в ASP.NET MVC? - PullRequest
1 голос
/ 21 июня 2011

Я использую ASP.NET MVC DefaultModelBinder для привязки запроса к классу модели, но только с использованием двух его свойств:

namespace MVCApp.Models
{
    public class Ticker
    {
        public string Symbol {get; set;
        public string Exchange {get; set;}
    }
}

namespace Domain //in another assembly
{
    public class Quote
    {
        public string Symbol {get; set; }
        public string Exchange {get; set; }
        //lots of other properties we need for output
    }
}

public ActionResult ShowQuote(Ticker ticker)
{
    var quote = quoteRespository.GetQuoteBy(ticker);
    return View(quote);
}

В представлении они могут указать тикери обмен;и это ModelBound с использованием DefaultModelBinder.Однако каждый раз, когда нам действительно нужно использовать этот объект Ticker для чего-либо, нам нужно перейти к QuoteRespository и получить все свойства, заполненные для этого тикера.

Вопрос

Должен ли я избавиться от объекта Ticker и просто создать привязку модели к привязке модели к объекту Quote;и в Modelbinder сделать вызовы репозитория, чтобы фактически заполнить объект Quote?Или я должен нарушить DRY и сделать звонок в этот репозиторий в каждом месте, где нам нужна цитата?Есть ли встроенный каркасный способ сделать это, которого мне не хватает?

Похоже, что существует школа, которая говорит , а не , чтобы делать вызовы уровня обслуживания вModelbinder .

Обновление

Я создал класс Ticker только потому, что у нас были эти два свойства в (почти) каждом действии:

public ActionResult ShowQuote(string symbol, string exchange)

Поскольку они всегда принадлежат друг другу, я создал небольшой класс Model на уровне пользовательского интерфейса, чтобы объединить их (вышеупомянутый класс Ticker). Тикер не является классом модели представления и не должен быть .

Ответы [ 3 ]

1 голос
/ 21 июня 2011

"Или я должен нарушить DRY и делать вызовы в этот репозиторий в каждом месте, где нам нужна цитата?

Вы всегда можете получить кавычку как часть функции OnActionExecuting контроллеров кавычек.

Я бы не стал считать это СУХИМЫМ нарушением. Просто стоимость ведения бизнеса. Скорее всего, способ получения котировок не изменится, и у вас, вероятно, будет <10 мест, где вам понадобится эта функция. Зависит от того, сколько раз вам нужно будет включить эту строку. </p>

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

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

0 голосов
/ 21 июня 2011

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

Таким образом, вы можете получить TicketViewModel, который содержит все необходимое для ваших представлений, и, как упоминал Дарин, использовать AutoMapper для сопоставления TicketViewModel с Quote.

РЕДАКТИРОВАТЬ:

Если вы действительно хотите обеспечить СУХОЙ, то вы можете создать свой собственный ModelBinder (это легко, тонны учебников в Google) и связать в нем свою модель представления из репозитория.

0 голосов
/ 21 июня 2011

Я бы использовал AutoMapper для сопоставления моделей представлений и моделей доменов.

...