Почему бы не использовать репозиторий в представлении

Question

У меня есть частичное представление, которое перебирает его Модель (список вещей), чтобы показать вещь. Имя и три целочисленных значения, которые являются счетчиками связанных сущностей.

Прежде всего, я попытался положить: (псевдо-бритва)

foreach(thing in Model){
    @thing.Name : 
        @thing.related.entities.where(condition1).Count()
        @thing.related.entities.where(condition2).Count()
        @thing.related.entities.where(condition3).Count()
}

Но это действительно медленно ... поэтому я создал функцию в ThingRepository, которая выполняет те же запросы быстрее, что-то вроде этого (псевдокод)

function GetCountofRelatedEntities(relatedID,condition){
    return db.entities.where(relatedID==relatedID && condition).count()
}

и это намного быстрее, поэтому я хочу назвать это. Я думаю, что я должен вызвать его из контроллера, но тогда мне нужен ViewModel, чтобы сохранить коллекцию (thing, Int, Int, Int) в качестве модели, или я могу использовать ViewBag чрезвычайно, чтобы передать результаты в представление, но, и вот вопрос: Почему бы просто не использовать репозиторий из представления? что не так с этим кодом в представлении? (Псевдо-бритва)

@repo=new ThingRepository()
foreach(thing in Model){
    @thing.Name : 
        @repo.GetCountofRelatedEntities(thing.relatedID,condition1)
        @repo.GetCountofRelatedEntities(thing.relatedID,condition1)
        @repo.GetCountofRelatedEntities(thing.relatedID,condition1)
}

Не могли бы вы сказать мне, почему я не должен создавать экземпляр хранилища внутри View? Или я могу это сделать?

Answer 1

Почему бы просто не использовать репозиторий из представления?

Потому что вы нарушаете шаблон проектирования MVC.Ответственность за представление не в том, чтобы получать данные.Он предназначен для отображения данных, которые передаются ему из контроллера в форме модели представления.И это так просто.

Вы можете вызывать репозитории или как угодно в своих представлениях, но больше не помечайте свои вопросы asp.net-mvc, потому что вы больше не делаете MVC.Я имею в виду, что вы можете делать все что угодно - вы даже можете писать SQL-запросы в своем представлении, если хотите.

Но весь смысл шаблона проектирования MVC состоит в том, чтобы отделить логику поиска данных от логики представления.

Answer 2

Одной из целей шаблона MVC является создание структуры, которая подходит для широкого диапазона распространенных ситуаций программирования. Для упрощения:

• Модель: описывает форму вашего приложения, то есть части вашего программного обеспечения, специфичные для вашего бизнеса.
• Просмотр: отображение данных для пользователя и передача пользовательских событий на сервер.
• Контроллер: действует как посредник между представлением и моделью.

То, что вы предлагаете, «работает» в том смысле, что оно получает данные на той странице, где вы этого хотите. В краткосрочной перспективе это экономит ваше время и усилия, так как вам не нужно беспокоиться о контроллерах, пакетах просмотра и т. Д.

Однако вы нарушаете структуру MVC таким образом, о котором вы, вероятно, пожалеете позже. Например, скажем, через несколько недель ваш босс приходит к вам и говорит: «Эй, вы знаете ту страницу, которую вы добавили, чтобы отобразить этот список сущностей? Нам нужно выполнить некоторую фильтрацию и сортировку по нему. И мне это нужно вчера».

Теперь перед вами стоит выбор: добавить эту логику фильтрации на страницу просмотра и уложиться в срок, или я потрачу время, чтобы перенести код доступа к данным на контроллер и переработать мое представление, рискуя пропустить срок и нарушить то, что уже работает?

Вы, вероятно, выберете легкий путь и добавите логику в представление, и теперь у вас в руках растущий беспорядок. Мы пошли по этому пути с приложениями VB6 и Webforms с 6000-строчными файлами кода. Поверь мне - ты не хочешь туда идти.

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

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

Answer 3

Моим главным возражением будет разделение интересов.Как только вы начинаете ударять по своей БД из своего представления, ваше «представление» больше не просто представление.Очень удобно иметь четкое разделение между вашим доступом к данным и вашим представлением.

Почему это разделение интересов важно?Это облегчает работу с системами, которые составлены с этим чистым разделением.Когда вам нужно настроить, какие данные будут извлечены, вам никогда не придется возиться с представлением.Пока представление получает правильное значение, оно будет отображаться правильно.Аналогичным образом, если вы хотите изменить способ отображения значений, вы можете изменить представление без каких-либо шансов обработки данных.

Answer 4

Дело в том, что в вашем View не должно быть никакой логики, потому что это не MVC подход.

MVC равно Seperation of concern.

Таким образом, вы должны создать свою ViewModel, которая содержит ALL данные, необходимые вашему View.