Создайте метод обратной передачи Ajax, который пишет файл CSV в Ваш веб-сервер и возвращает URL.. Установите скрытый IFrame в браузере к местоположению файла CSV на сервере.
Вашему пользователю тогда подарят ссылку на загрузку CSV.
Я бы настоятельно рекомендовал связать эти данные вместе, возможно, как пару, но больше как конкретный контейнер. Таким образом, вы можете ввести дополнительную функциональность, связанную с этими двумя объектами.
Хранение двух списков по отдельности будет проблемой. Вам придется передавать оба вместе и синхронизировать их. Накладные расходы на создание нового объекта для этого незначительны, и именно для этого предназначено ООП (вы будете создавать классы, отличные от JDK, просто написав новый код Java для своего приложения, не забывайте).
Я создаю второстепенные классы любят это все время. Они обеспечивают строгую безопасность типов и предоставляют возможности для улучшения и рефакторинга. IDE могут более легко идентифицировать и выполнять рефакторинг.
Почему бы не использовать Словарь (тип карты, как бы Java ни называла его в настоящее время, я думаю, что раньше это было ] Хеш-таблица
)? Это позволит сопоставить идентификаторы со значениями и обойти вашу дилемму.
Я бы выбрал Список
из пар
, если два целых числа действительно принадлежат друг другу и должны представлять «одно».
Еще одним недостатком использования двух отдельных списков является то, что компилятор не проверяет, всегда ли списки одного размера. И вы оставляете интерпретацию на усмотрение клиента вашего метода; клиенту необходимо сопоставить элементы в двух списках.
Я не считаю использование класса типа Pair
большим недостатком, «потому что он полагается на классы, не относящиеся к JDK», как вы говорите , но если вы действительно не хотите использовать что-то вроде Pair
, вы даже можете сделать его списком массивов: List
, где каждый массив содержит два Целочисленные
объекты.
Когда API является общедоступным, убедитесь, что вы реализуете только основные функции, потому что все, что вы даете клиенту, никогда не может быть возвращено.
Подумайте о методе с назначением всего 2 параметров (целое число entityId, Integer someOtherId) и позвольте клиенту выяснить, как добавить больше элементов.
Если вы хотите разрешить удобный доступ, дайте им класс util, который поставляется с интерфейсом «Assignment», который просто определяет getEntityId () и getSomeOtherId ( ) и с реализацией по умолчанию, такой как DefaultAssignment, которая содержит окончательные ссылки на идентификаторы.
Затем ваши клиенты могут выбирать, каким путем они хотят идти, и вам не нужно обязательно поддерживать свой класс «Pair».
Мне кажется, что проведенный вами анализ уже очень хорошо определяет плюсы и минусы этих двух методов.
Я также склоняюсь к использованию пары
класс, сославшись на перечисленные вами преимущества:
- Более точно отражает реальную отношения между объектами
- Устраняет некоторые классы динамических ошибка (например, несоответствие длины списка)
Самым большим для меня было бы первое.
Всегда пишите код, который демонстрирует намерение. Не программируйте, думая исключительно о реализации.
Использование класса типа Pair
показывает намерение, что существует пара значений, которая представляет идентификатор и саму сущность. Он также показывает, что один объект Pair
- это одна дискретная единица данных, которую необходимо обрабатывать вместе - то, что не может быть получено из двух отдельных List
идентификаторов и объектов.
Подход со списком пар - очевидная вещь, поскольку он более точно отражает намерение, но карта может быть даже лучше, если идентификаторы уникальны.
Если у вас есть ] миллионов этих пар, и потребление памяти становится основным соображением, вы можете переключиться на пары списков (поскольку в каждой паре будет на один объект меньше).
Я наполовину не согласен с этим:
, потому что, хотя и не существует класса Pair
в JDK есть интерфейс: Map.Entry
, который соответствует вашему предполагаемому использованию в качестве ассоциации ключ / значение.
На мой взгляд, используйте список пар (или ваш собственный, более конкретный контейнер), поскольку он, кажется, наиболее естественно отражает проблему, которую вы решаете. И это только одна переменная, которую нужно отслеживать и отправлять в методы, а не две.
Сначала напишите модульные тесты. Тогда вы легко увидите, с чем проще всего работать, и затем выберите это в качестве своей реализации.
Вы можете подумать о том, чтобы сделать параметр Итератором
. Если у вызывающего класса есть List
, получение итератора тривиально. В противном случае создание итератора может быть проще, быстрее и / или естественнее. В некоторых случаях это может даже помочь устранить проблемы нехватки памяти.
Используйте список пар или карту.
Я не покупаю ни один из аргументов "против" вы перечислили.
Вы всегда должны ошибаться в сторону большей абстракции. Вы пишете объектно-ориентированный язык, а инкапсуляция и скрытие информации на мой взгляд, самая главная причина мыслить предметами. Он скрывает детали реализации от пользователей, позволяя им сосредоточиться на том, что предоставляет ваш класс. Они могут забыть о том, как ваш класс выполняет то, что они хотят. Вынуждая ваших клиентов вести два списка, вы просите их знать больше, чем им нужно.