Файлы в доменной модели

Question

Каковы лучшие практики для работы с двоичными файлами в доменной модели? Мне часто приходится связывать изображения и другие файлы с бизнес-объектами, и простой байт [] не подходит даже для самых простых случаев.

Файлы:

• Не имеет фиксированного размера и может быть довольно большим, таким образом:
  • Должны быть потоковыми или буферизованными, предпочтительно асинхронным образом;
  • Должно кэшироваться как на сервере, так и на клиенте, чтобы избежать избыточной передачи;
  • На ненадежных соединениях передача данных может быть легко прервана и должна быть возобновлено - поэтому передача может начаться не с начала файла, а с произвольной позиции.
• Обрабатываются иначе, чем остальные данные:
  • В веб-приложениях не являются частью содержимого страницы, но загружаются браузером отдельно;
  • Может быть черный ящик, который обрабатывается сторонним программным обеспечением;
  • По соображениям производительности может даже не храниться в базе данных.

Как мы можем выражать такие файлы в модели предметной области (или, более конкретно, в классах модели)? Если остальная часть модели передается через DTO и веб-службы WCF и сохраняется с NHibernate в базе данных, но файлы не обязательно должны быть такими, как сделать обработку файлов прозрачной, частью общей транзакции, где это применимо, и при этом поддерживать все, что необходимо для их использования не только в веб-приложениях, но и в обычных настольных приложениях.

Для WPF и ASP.NET файловый объект должен предоставлять некоторую форму свойства Url, которое можно привязать к данным для элементов управления WPF или использовать в тегах IMG или HTML. Загрузка файла намного сложнее. Предпочтительно, чтобы там поддерживались надлежащие методы представления и контента, такие как MVVM.

Я действительно потерян здесь, потому что я не удовлетворен ни одним из моих предыдущих решений. Что бы вы посоветовали?

Answer 1

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

У вас должна быть концепция представления файла, которую можно передавать везде, как вы определили, - но это должно быть немного больше, чем идентификатор и, возможно, имя - тогда все зависит от отдельных компонентов, чтобы решить, как они обрабатывают это, например, HTML-страница может использовать объект File json и делать вывод, что jsFile.Id нужно получить, используя ftp: // xxx / uploads / {id} или что-то еще, чтобы отображать дополнительную связанную информацию, чтобы служба WCF могла получить идентификатор файла и найти информацию в базе данных.

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