Должна ли сортировочная логика размещаться в модели, представлении или контроллере?

Ответ 1

(Примечание: эта цитата и цитата взяты из @dasblinkenlight answer, но мы не согласны с ее интерпретацией, читаем его сообщение и твоим собственным умом).

Согласно описание MVC,

Контроллер может отправлять команды в связанное с ним представление, чтобы изменить представление представления модели (например, путем прокрутки документа). Он может отправлять команды модели для обновления состояния модели (например, редактирования документа).

Логика сортировки (например, алгоритм сортировки/сортировки сортировки) принадлежит модели, поскольку она содержит бизнес-правила и данные состояния. Поскольку изменение способа сортировки данных модели попадает прямо в категорию "изменить представление представления модели", контроллер отвечает за "выполнение сортировки", вызывая метод model.changeSortedState().

Ответ 2

Кто контролирует порядок сортировки?

(Из Wikipedia)

1) Естественный порядок внутри самих данных:

Заказ является частью Модели, поэтому он должен идти туда. Необработанное нажатие "всех данных" вернет данные в отсортированном порядке, и нет никакого интерфейса для выбора порядка сортировки.

2) Пользователь должен контролировать, как они видят данные:

В представлении будет представлен интерфейс (например, восходящие/нисходящие стрелки), которые взаимодействуют с контроллером, а модель хорошо понимает данные, чтобы выполнить запрошенный сортировку данных. Однако необработанное вытягивание данных необязательно необходимо сортировать, в отличие от (1).

В любом случае

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

Небольшое предостережение

Функциональность сортировки может идти исключительно в представлении при одном обстоятельстве (о котором я могу думать небрежно, может быть и больше):

"тупой" вид, где все данные уже находятся в представлении, и ему не нужно использовать какое-либо знание домена для сортировки. Например, очень простое сравнение строк или чисел. Это невозможно, например, в результатах поиска на веб-странице, когда результаты, вероятно, будут разбиты на несколько страниц.

Ответ 3

Согласно описание MVC,

Контроллер может отправлять команды в связанное с ним представление, чтобы изменить представление представления модели (например, путем прокрутки документа). Он может отправлять команды модели для обновления состояния модели (например, редактирования документа).

В соответствии с этим логика сортировки принадлежит контроллеру, так как изменение способа сортировки данных модели прямо относится к категории "изменить представление представления модели".

РЕДАКТИРОВАТЬ: Чтобы прояснить несколько недоразумений, высказанных в комментариях, "логика сортировки" - это не код, который выполняет сортировку; это код, который определяет сортировку. Логика сортировки сравнивает отдельные элементы друг с другом, чтобы установить порядок (например, через экземпляр IComparator<T>) или содержит логику, которая строит объект, который будет использоваться для упорядочения внешней системой (например, через экземпляр IOrderedQueryable<T>). Эта логика принадлежит вашему контроллеру, потому что ему нужны знания, относящиеся к "бизнес-стороне" вашего приложения. Это вполне достаточно, чтобы выполнить сортировку, но она отделена от кода, который ее фактически выполняет. Код, который сортируется, может быть в вашем представлении, в вашей модели или даже на уровне сохранения, который поддерживает вашу модель (например, вашу базу данных SQL).

Ответ 4

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

Что я обычно делаю в своих приложениях MVC, у меня есть уровень сервиса, который выполняет всю бизнес-логику. Методы на сервисном уровне должны иметь чистый, простой API с хорошо именованными параметрами. Затем вы можете вызвать эти методы с вашего контроллера, чтобы манипулировать данными в моделях.

В этом смысле сортировка "находится в контроллере", но сам код, который выполняет сортировку, не должен реализовываться в контроллере, только вызываемый оттуда.

Ответ 5

Определенно не контроллер: он отправляет сообщения для просмотра и моделирования, но должен делать как можно меньше работы. Если пользователь может изменить сортировку, которую запрос обрабатывает контроллером, проинформировав модель или представление о ней.

Может быть, View, если это чистая вещь. Если приложение работает так же, как и без сортировки, сортировка является лишь частью представления и должна идти в представлении.

Если упорядочение является неотъемлемой частью домена, оно должно идти в модели.

Ответ 6

• Представления являются частью MVC, которая должна содержать логику представления.
• Уровень модели, где содержится бизнес-логика.
• Контроллеры изменяют только состояние обоих, на основе пользовательского ввода.

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

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

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

Ответ 7

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

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

Является ли это средним/большим приложением и/или имеет несколько пользовательских интерфейсов, связанных с ним (например, приложение Windows, веб-интерфейс и интерфейс телефона).

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

Если это хорошо определенный единый веб-сайт пользовательского интерфейса, и вы используете что-то вроде EF Code First, и у вас нет или нет намерения создать сервисный уровень и планируете использовать простой из коробки метод расширения для его получения

• В этом случае я, вероятно, поставил бы его в контроллер как прагматично его наилучшим образом соответствует времени/бюджету.

Если это то же самое, что и выше, BUT не может быть реализовано с помощью метода расширения из коробки.

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

Подводя итог:

Догматический ответ: Уровень обслуживания

Прагматичный ответ: обычно контроллер

Ответ 8

Ваша модель должна содержать данные.

Ваше представление должно содержать способ представления данных.

Контроллер должен содержать данные о ваших данных.

Итак, ответ - это контроллер, так как сортировка - это определенно манипуляция.

Ответ 9

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

Если вы решили сделать сортировку вручную, я считаю, что есть хорошие аргументы в пользу использования модели или контроллера в качестве предпочтительного места для логики. Ограничение будет вашей конкретной структурой. Я предпочитаю управлять данными исключительно в модели. Я использую контроллер, чтобы вступать в брак с данными (моделью) и представлением (представлением), как я был (сам) преподавал.

Ответ 10

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

НО... Эти ответы, похоже, не учитывают успехи в технологии ORM, я могу говорить только по отношению к платформе Entity Framework (позвольте избежать аргумента относительно того, является ли это истинным ORM, это не точка) от Microsoft как того, что я использую, но я уверен, что другие ORM предлагают аналогичную функциональность.

Если я создаю строго типизированное представление для класса Product с использованием MS MVC и Entity Framework, и существует связь внешнего ключа между таблицей Product and Image (например, FK_Product_Image_ProductId), тогда я мог бы быть в состоянии для быстрого сортировки изображений во время их отображения с помощью чего-то подобного в представлении:

@foreach(Image i in Model.Image.OrderBy(e => e.DisplayOrder)){ //etc etc... }

Было упомянуто о конкретном уровне бизнес-логики, который я также использую для выполнения 80% моей бизнес-логики, но я не собираюсь писать функции сортировки в свой уровень Business Logic, который имитирует что-то, что выходит из- the-box из Entity Framework.

Я не думаю, что есть правильный ответ на этот вопрос, кроме как сказать это; вы должны абстрагировать сложную бизнес-логику, где это возможно, но не ценой заново изобретать колесо.

Ответ 11

Предположим, что у вас есть веб-сайт MVC, веб-сайт WebForms и мобильное приложение.

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

В противном случае я бы сохранил эту логику в модели представления. Зачем? Потому что он будет многоразовым и легко проверяемым.

Ответ 12

Из трех перечисленных вами я бы сказал, что он принадлежит контроллеру. Я действительно не люблю размещать такую ​​логику в контроллере. Обычно я создаю уровень сервиса, с которым контроллер связывается с ним, и будет отвечать за связь с хранилищем данных и обработку логики сортировки. Тем не менее, для небольших приложений он прекрасно сидит в контроллере.

Ответ 13

Это вопрос, заданный с учетом asp.net, но, поскольку кто-то упоминал Rails, я подумал, что было бы интересно рассмотреть проблему в этом контексте. В Rails естественно и довольно часто выполнять сортировку вместе с поиском в качестве действия контроллера, поскольку для него предусмотрены рамки и ActiveRecord/ActiveQuery api. С другой стороны, можно определить какой-то пользовательский порядок сортировки для статических элементов и поместить его в модель, которая будет использоваться контроллером, поэтому модель может играть роль в логике сортировки, даже если она не выполняет операция непосредственно. Независимо от того, что это такое, можно с уверенностью сказать, что размещение логики сортировки в представлении обычно недооценивается.

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