Разработка

Правила сокрытия подсказывают, что доступ к членам класса напрямую должен быть закрыт. Доступ должен осуществляться через специальные методы доступа. В большинстве случаев именно так и стоит поступать. Это не столько защищает члены от изменения извне, сколько позволяет не думать (сокрытие) о жизненном цикле и процессе инициализации членов, к которым необходимо обращаться.

Единственным допустимым исключением считаю доступ к членам немутабельных классов, являющихся по-факту структурами. Примером может служить класс, реквизиты которого содержат некоторые подсчитанные итоговые значения. Реквизиты должны быть при этом объявлены как неизменяемые (final) и представлять собой преимущественно простые типы. Польза тут в том, что если обращение к этим реквизитам будет происходить в выражениях, читать такие выражения легче --- отсутствуют скобки вызова метода, и можно не задумываться о побочном эффекте.

В данный момент считаю, что в нашем случае валидацию лучше отключить. Толку от неё мало, больше помех, так как из-за неё не возможно воспользоваться отладчиком. Пусть уж лучше упадёт обработка сообщения в конкретном месте, чем тупо валидатор его отбросит, и не понятно, в чём именно дело.

Пример пространства имён:

http://finance.glance.ru/partner

Первая часть обозначает тип системы в компании. Фрагменты данной части имени записываются в том же порядке, как и адреса web (не в обратном, как пакеты в Java). Вторая часть (после косой черты) обозначает часть системы (часть предметной области), к которой относится данное пространство имён.

В приведённом выше примере пространство имён относится к системам "Казначейство" (finance.glance.ru), а именно, к информации о контрагентах (partner).

1С вообще ведёт иногда себя очень странно и не предсказуемо. Поэтому при разработке веб-сервисов стоит придерживаться какого-либо определённого соглашения.

  1. Рекомендую для передачи параметров в функцию веб-сервиса всегда использовать единственный параметр. Тип этого параметра должен быть описан в пакете. Внутри этого параметра может содержаться необходимое количество реквизитов. Так проще работать с необязательными параметрами запроса.
  2. Вообще все типы лучше описывать в пакете явно, а не делать их анонимными. У веб-сервиса на стороне 1С нет других шансов, кроме работы через фабрику XDTO. Поэтому должна быть возможность добраться до типов, чтобы можно было создавать соответствующие элементы.

Когда 8.1 выступает в качестве клиента, лучше всего не полагаться на XDTO, а предпочесть работу по типу REST. Лучше использовать при этом не встроенные средства для работы с XML, а стандартный MSXML.

  • Встроенные средства не позволяют отправлять запрос из памяти (только из файла).
  • MSXSML умеет возвращать готовый XML DOM в качестве ответа на запрос. Если же вынимать из него текст и строить DOM средствами 1С, возникает дополнительный оверхед.
  • В качестве запроса MSXML тоже можно передать ссылку на COM с DOM-объектом.

В 1С 8.3 средства для работы с XML уже более зрелые, там этого соглашения придерживаться не стоит.

Кстати, API MSXML лучше уточнять в оффлайновом файле справке от MSXMLSDK. В вебе MSDN очень запутанный, найти там то, что нужно, быстро не получается.

При формировании сообщений XML или JSON, узлы нужно называть по-английски. Это более универсальный вариант, так как не весь код пишется на 1С, и лучше сразу иметь возможность работать с любым сообщением, не нуждаясь в конвертации. При этом обязательно следует использовать тезаурус, иначе будет хаос в используемых терминах и именах.