Вопросы Теги

Какой подход дистанционной работы для JAVA-приложения Вы рекомендовали бы?

Внимание: Пожалуйста, смотрите Ответ Льва Дабуса для правильной реализации Swift 4.

Swift 4

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

Попробуйте здесь 

extension String {
  subscript (i: Int) -> Character {
    return self[index(startIndex, offsetBy: i)]
  }
  subscript (bounds: CountableRange) -> Substring {
    let start = index(startIndex, offsetBy: bounds.lowerBound)
    let end = index(startIndex, offsetBy: bounds.upperBound)
    return self[start ..< end]
  }
  subscript (bounds: CountableClosedRange) -> Substring {
    let start = index(startIndex, offsetBy: bounds.lowerBound)
    let end = index(startIndex, offsetBy: bounds.upperBound)
    return self[start ... end]
  }
  subscript (bounds: CountablePartialRangeFrom) -> Substring {
    let start = index(startIndex, offsetBy: bounds.lowerBound)
    let end = index(endIndex, offsetBy: -1)
    return self[start ... end]
  }
  subscript (bounds: PartialRangeThrough) -> Substring {
    let end = index(startIndex, offsetBy: bounds.upperBound)
    return self[startIndex ... end]
  }
  subscript (bounds: PartialRangeUpTo) -> Substring {
    let end = index(startIndex, offsetBy: bounds.upperBound)
    return self[startIndex ..< end]
  }
}
extension Substring {
  subscript (i: Int) -> Character {
    return self[index(startIndex, offsetBy: i)]
  }
  subscript (bounds: CountableRange) -> Substring {
    let start = index(startIndex, offsetBy: bounds.lowerBound)
    let end = index(startIndex, offsetBy: bounds.upperBound)
    return self[start ..< end]
  }
  subscript (bounds: CountableClosedRange) -> Substring {
    let start = index(startIndex, offsetBy: bounds.lowerBound)
    let end = index(startIndex, offsetBy: bounds.upperBound)
    return self[start ... end]
  }
  subscript (bounds: CountablePartialRangeFrom) -> Substring {
    let start = index(startIndex, offsetBy: bounds.lowerBound)
    let end = index(endIndex, offsetBy: -1)
    return self[start ... end]
  }
  subscript (bounds: PartialRangeThrough) -> Substring {
    let end = index(startIndex, offsetBy: bounds.upperBound)
    return self[startIndex ... end]
  }
  subscript (bounds: PartialRangeUpTo) -> Substring {
    let end = index(startIndex, offsetBy: bounds.upperBound)
    return self[startIndex ..< end]
  }
}

Чтобы преобразовать Substring в String, вы можете просто сделать String(string[0..2]), но вы должны делать это только если вы планирую держать подстроку вокруг. В противном случае более эффективно сохранить его Substring.

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

& nbsp;

Swift 3: 

extension String {
  subscript (i: Int) -> Character {
    return self[index(startIndex, offsetBy: i)]
  }
  subscript (i: Int) -> String {
    return String(self[i] as Character)
  }
  subscript (r: Range) -> String {
    let start = index(startIndex, offsetBy: r.lowerBound)
    let end = index(startIndex, offsetBy: r.upperBound)
    return self[Range(start ..< end)]
  }
}

& nbsp;

Почему это не встроено?

Apple предоставляет следующее объяснение ( найдено здесь ):

Подписывание строк с целыми числами недоступно.

Понятие «i-й символ в строке» имеет разные интерпретации в разных библиотеках и компонентах системы. Правильная интерпретация должна быть выбрана в соответствии со случаем использования и задействованными API, поэтому String не может быть подписано целым числом.

Swift предоставляет несколько различных способов доступа к символьным данным, хранящимся внутри строк.

  • String.utf8 - это набор кодовых единиц UTF-8 в строке. Используйте этот API при преобразовании строки в UTF-8. Большинство API POSIX обрабатывают строки в единицах кода UTF-8.

  • String.utf16 - это набор кодовых единиц UTF-16 в виде строки. Большинство сенсорных API-интерфейсов Какао и Какао обрабатывают строки в единицах кода UTF-16. Например, экземпляры NSRange, используемые с NSAttributedString и NSRegularExpression, хранят смещения и длины подстрок в единицах кода UTF-16.

  • String.unicodeScalars - это коллекция скаляров Unicode. Используйте этот API, когда вы выполняете низкоуровневую манипуляцию с символьными данными.

  • String.characters представляет собой набор расширенных кластеров графем, которые являются приближением воспринимаемых пользователем символов.

Обратите внимание, что при обработке строк, содержащих читаемый человеком текст, следует избегать посимвольной обработки в максимально возможной степени. Вместо этого используйте высокоуровневые чувствительные к локали алгоритмы Unicode, например, String.localizedStandardCompare(), String.localizedLowercaseString, String.localizedStandardRangeOfString() и т. Д.

7
задан Tomasz Błachowicz 3 July 2009 в 10:02
поделиться

6 ответов

Попробовав несколько технологий удаленного взаимодействия и обнаружив, что они универсально не работают, я бы теперь использовал удаленное взаимодействие Spring как абстракцию от реализации. Это позволяет вам сосредоточиться на написании своей функциональности и позволить Spring обрабатывать удаленную часть с некоторой конфигурацией. у вас есть выбор из нескольких реализаций (RMI, HTTP-инициатор Spring, Hessian, Burlap и JMS). Абстракция означает, что вы можете выбрать одну реализацию и просто поменять ее местами, если ваши потребности изменятся. Дополнительную информацию см. В документации SpringSource .

8
ответ дан 6 December 2019 в 14:07
поделиться

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

Действительно ли вы запускаете каждую службу на отдельной виртуальной машине? Если эти EJB-компоненты всегда взаимодействуют друг с другом, вам лучше всего поместить их в одну и ту же виртуальную машину и избегать любых удаленных вызовов процедур, поскольку эти службы могут использовать свои LocalInterfaces.

Другая вещь, которая может вас укусить, - это использование POJO Hibernate. Вы можете подумать, что это простые POJO, но за кулисами Hibernate был занят CGLib, пытаясь делать такие вещи, как разрешить ленивую инициализацию. Если эти bean-компоненты сериализуются и передаются через удаленные границы, вы можете получить странное исключение Hibernate. Лично я бы предпочел создавать простые DTO или записывать POJO в виде XML для передачи между компонентами. Мои коллеги пошли бы еще дальше и написали бы собственные протоколы проводов для передачи данных из соображений производительности.

Недавно я использовал MULE ESB для интеграции различных компонентов служб. Это довольно приятно, так как вы можете иметь сочетание RMI, сокетов, веб-сервисов и т. Д. Без необходимости писать большую часть стандартного кода.

http://www.mulesource.org/display/COMMUNITY/Home

3
ответ дан 6 December 2019 в 14:07
поделиться

Зачем вам использовать что-то, кроме самого простого, что работает?

В вашем случае это звучит как EJB3 или, возможно, JMS, в зависимости от того, должно ли взаимодействие быть синхронным или асинхронным.

EJB3, безусловно, проще всего построить поверх RMI с контейнером, обеспечивающим все дополнительные функции, которые могут вам понадобиться - безопасность, транзакции и т. Д. Предположительно ваши POJO находятся в совместно используемом jar-хранилище и, следовательно, могут просто передаваться между вашими EJB. , хотя я сам склонен передавать объекты-значения. Другое преимущество EJB заключается в том, что при правильном использовании он является наиболее производительным (это, кстати, только мое мнение; -).

JMS немного более задействован, но не намного, и система, основанная на асинхронном взаимодействии, предоставляет определенные тонкости в сроки распараллеливания задач и др.

2
ответ дан 6 December 2019 в 14:07
поделиться

Если вам нужна сетевая связь между Java-приложениями, вам подойдет Java RMI. У него лучшая интеграция, наибольшая прозрачность и наименьшие накладные расходы.

Если, однако, некоторые из ваших клиентов не основаны на Java, вам, вероятно, следует рассмотреть другие варианты (Java RMI фактически имеет диалект IIOP, который позволяет ему однако для взаимодействия с CORBA - я бы не рекомендовал это делать, если только это не связано с некоторой интеграцией устаревшего кода). В зависимости от ваших потребностей веб-сервисы, вероятно, станут вашим другом. Если вас беспокоит нагрузка на сеть, вы можете использовать веб-сервисы через Hessian.

1
ответ дан 6 December 2019 в 14:07
поделиться

Вы буквально имеете в виду удаленно? Например, при работе в другой среде с разными характеристиками доступности? Из-за сетевых накладных расходов?

Предполагая, что «да», моим первым шагом было бы использовать сервисный подход, отложив на мгновение технологию вызова. Просто подумайте о дизайне и значении ваших услуг. Вы знаете, что их вызывать сравнительно дорого, поэтому небольшие загруженные интерфейсы - это плохо. Вы знаете, что система обслуживания может давать сбой между вызовами, поэтому вы можете отдать предпочтение службам без отслеживания состояния. Вам может потребоваться повторить запросы после сбоя, поэтому вы можете отдать предпочтение идемпотентным схемам обслуживания.

Затем рассмотрите отношения доступности. Может ли ваш клиент работать без удаленной системы. В некоторых случаях вы просто не можете прогрессировать, если удаленная система недоступна (например, может ' t включите сотрудника, если вы не можете получить доступ к системе управления персоналом) в других случаях вы можете принять философию «стреляй и скажи мне позже»; ставьте в очередь запросы и обрабатывайте ответы позже.

Там, где есть зависимость доступности, кажется, подходит простое предоставление синхронного интерфейса. Вы можете сделать это с помощью SLSB EJB, если все работает на Java EE. Я склонен обобщать, ожидая, что если мои услуги будут полезны, то они могут понадобиться и клиентам, отличным от Java EE. Итак, SOAP (или REST) ​​имеет тенденцию быть полезным. В наши дни добавление интерфейса веб-службы к SLSB довольно тривиально.

Но моя любимая теория состоит в том, что любая достаточно большая ИТ-система в конечном итоге требует постоянной связи: вам нужно разделить ограничения доступности. Поэтому я бы предпочел искать отношения в стиле JMS. Фасад MDB перед вашими услугами, или SOAP / JMS не так уж и сложно. Такой подход имеет тенденцию выдвигать на первый план проблемы проектирования на случай отказа, которые, вероятно, так или иначе скрывались, JMS имеет тенденцию заставлять вас думать: «предположим, я не получу ответа? Предположим, что мой ответ придет поздно?»

1
ответ дан 6 December 2019 в 14:07
поделиться

Я бы выбрал SOAP.

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

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

С помощью мыла вы можете (но не обязаны) иметь дело с безопасностью сертификатов и безопасными соединениями в общедоступных сетях . Поскольку протоколом по умолчанию является HTTP через порт 80, у вас будет минимальная проблема с брандмауэрами и т. Д. SOAP также отлично подходит для гетерогенных клиентов (в вашем случае для всего, что не является J2EE) с хорошей поддержкой большинства распространенных языков на большинстве распространенных платформ.

0
ответ дан 6 December 2019 в 14:07
поделиться
Другие вопросы по тегам:

Похожие вопросы: