Блог

Главная - Вопросы по программированию - Вложение изображения как часть DTO или отдельная загрузка (ASP.NET MVC 2 и WCF REST)

Вложение изображения как часть DTO или отдельная загрузка (ASP.NET MVC 2 и WCF REST)

#wcf #asp.net-mvc-2 #wcf-rest

#wcf #asp.net-mvc-2 #wcf-rest

Вопрос:

У меня есть существующее ASP.NET Клиентское приложение MVC 2, которое использует приложение-службу RESTful WCF для сохранения данных. Появилось новое требование для поддержки изображения, прикрепленного / связанного с одним из моих существующих объектов домена (Product).

В настоящее время клиентское приложение вызывает службу для получения списка продуктов (в виде списка облегченных объектов ProductInfo) и отображает список пользователю. Когда пользователь нажимает на элемент в списке, клиент вызывает службу, чтобы получить конкретный объект Product, который поддерживает редактирование пользователем. После сохранения клиент отправляет обновленный продукт в службу для сохранения.

Новое требование требует, чтобы я отображал связанное изображение в списке, а также разрешал пользователю устанавливать / заменять изображение при редактировании продукта. Текущее изображение также отображается в редакторе продукта. С каждым продуктом будет связано только одно изображение, и оно будет обязательным.

  1. Является ли Stream лучшим способом передачи данных изображения между клиентом и сервером или мне следует использовать Byte []?

  2. Для списка было бы разумно добавить новое свойство изображения в ProductInfo типа Stream (или Byte[]) или потребовать отдельного вызова службы для загрузки изображения?

  3. Аналогично, для редактирования я просто обрабатываю данные изображения как любое другое свойство и передаю их туда и обратно по проводу, используя свойство изображения?

Ответ №1:

Является ли Stream лучшим способом передачи данных изображения между клиентом и сервером или мне следует использовать Byte []?

Это будет зависеть от используемой вами привязки, но с SOAP, даже если вы выберете Stream, в конечном итоге, когда сериализатору потребуется отправить его по сети, это будет массив байтов в кодировке base64.

Для списка было бы разумно добавить новое свойство изображения в ProductInfo типа Stream (или Byte[]) или потребовать отдельного вызова службы для загрузки изображения?

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

Другая возможность — загрузить все изображения за один раз из службы WCF, а затем вызвать действие контроллера, которое загрузит их с помощью AJAX. Затем вставьте их в HTML как данные base64 (как это делает Google с предварительными просмотрами изображений на странице результатов)

Аналогично, для редактирования я просто обрабатываю данные изображения как любое другое свойство и передаю их туда и обратно по проводу, используя свойство изображения?

Для редактирования у вас может быть сервисный метод, который будет принимать массив байтов и идентификатор элемента, который вы обновляете.

Комментарии:

1. Я использую службу WCF REST, поэтому webHttpBinding, которая не использует SOAP.

2. Моя проблема с использованием отдельных методов обслуживания при редактировании продукта заключается в том, что у меня будет 1 вызов для получения сведений о продукте и еще один для получения изображения, отображения их пользователю, разрешения им вносить изменения, скажем, в описание продукта и изображение, затем отправлять изменения обратно в службу в одной операции для обновления описания и другой для обновления изображения. Это 4 вызова службы для 2 операций (получение и обновление). Действительно ли это лучший способ справиться с этим? Проще говоря, есть ли что-то неправильное во включении данных изображения с другими свойствами при получении и отправке продукта?

3. @SonOfPirate, если вы включите данные изображения как часть продукта (a byte[] ), как вы собираетесь отображать их в HTML? В конце концов, <img> ожидает, что его src свойство будет указывать либо на действие сервера, которое вернет данные изображения, либо на встроенную кодировку base64.

4. Хороший вопрос. Мои первые мысли заключаются в том, что я бы вернул FileResult (используя метод File в классе Controller) из метода действия ProductImage. Но это означало бы, что мне пришлось бы сохранить исходный объект в сеансе или что-то еще для поддержки второго вызова для рендеринга изображения. Хммм…

Ответ №2:

Хотя я ценю ответ Дарина и изначально шел по этому пути, в итоге я выбрал тот же подход, описанный в Pro ASP.NET Платформа MVC 2.

В главе 6 описывается, как изображение может быть загружено как часть страницы редактирования объекта Product, а затем отображено с помощью действия контроллера на другой странице. Единственное отличие в моем приложении заключается в том, что сохранение обрабатывается на другом уровне через интерфейс веб-службы RESTful. Однако, основываясь на подходе, показанном в книге, я решил использовать единый DTO, который содержит свойства для двоичных данных изображения и информацию о строковом типе MIME.

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