Разделение проблем и производительности?

Question

У меня есть ASP.NET MVC сайт, и я пытаюсь выяснить разделение функций контроллера и модели (репозитория) и помощника HTML.

Цель состоит в том, чтобы запросить у базы данных информацию о фотоальбомах и сгруппировать ее по годам.

Шаги:

1. Запрос к базе данных и возврат данных из базы данных.
2. Преобразовать данные в коллекцию альбомов (список)
3. Bucket альбомы по годам в ALbumDictionary
4. Отображать каждый год в отдельной таблице HTML.

Учитывая этот запрос, я мог видеть: 1,2,3 все в модели, и контроллер просто связывает вид с моделью AlbumDictionary или же 1,2 в модели и привязка к коллекции альбомов и 3 в HTML ViewHelper или же 1,2 в модели 3 в контроллере и привязка к Альбому

Мысли

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

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

Answer 1

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

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

Answer 2

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

Я вижу группировку по годам, довольно близкую к визуализации. Вот почему я не поместил бы это в Модель и также не в Контроллер. Распространенным подходом является наличие модели Poco и DAL / BLL и другой модели под названием ViewModel (модель, используемая строго типизированным представлением). Это хорошее место для подготовки объектов к визуализации.

В ViewModel я бы использовал Linq для группировки альбомов по годам. Надеюсь, это будет достаточно быстро.

Answer 3

Я бы сделал бэкетинг в контроллере, только если либо:

• разбивка происходит только один раз, и я могу сделать это с помощью одного или двух простых операторов;

• Это происходит несколько раз, но я могу сделать это только с помощью оператора AlbumDictionary.BucketByYear().

В противном случае я бы использовал модели для этого.