У меня есть справочник «Пользователи» должен автоматически синхронизироваться со списком пользователей в программе. Для этого при старте приложения проверяем, есть ли текущий пользователь в справочнике. Если нет, его нужно программно добавить. А также мне при старте нужно узнать, является ли пользователь администратором.

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

Т.е. я могу один раз вызвать сервер и получить ответ - админ или не админ. Но тогда у меня получается громоздкое название функции. Что-то типа ПроверитьПользователяИСообщитьАдминЛи.

Код будет более читаемым, если создать две функции:
1) ПроверитьПользователя(Пользователь);
2) УзнатьАдминЛи(Пользователь);

Но тогда надо вызывать два раза сервак. Как лучше поступить?

Один вызов лучше.

Админ = Неопределено;
ПроверитьПользователя(Пользователь, Админ);

а то что при старте приложения ты и так сначала на сервере?

Старт приложения редкая операция, по этому 2 вызова мало на что влияют. Реально 1 вызов лучше, но 2 при старте не смертельнл

(1) Дык. Не читается код. Если функция возвращает булево, значит, функция должна быть общим вопросом (подразумевает только ответ да или нет).

Если написать ПроверитьПользователя, то ну никак не очевидно, что означает да или нет.

Не нравится. У меня хоть и не так складно, но понятнее - ПроверитьПользователяИСообщитьАдминЛи.

(1) Я как потом жить-то должен?
Если НЕ ПроверитьПользователя.ОпределитьТекущегоПользователя()

Если это хороший стиль, то что тогда плохой?

(1) Т.е. мне же надо знать, админ или нет.

Вот я и пишу:

Если НЕ ПроверитьПользователя() Тогда

Как-то это все не так, а?

(5)

Админ = Неопределено;
ПроверитьПользователя(Пользователь, Админ);

Если Не Админ Тогда

(7) Да, так лучше, пожалуй. Спасибо.

Хороший стиль - возвращать структуру. Сегодня админ, завтра роли, послезавтра еще что-то захочешь.

А (1) (7) плохой стиль. Побочные эффекты - это плохая читаемость и сопровождаемость.

А почему бы не так?

Если ПолучитьАдмПолномочияПользователя(Пользователь) Тогда

Функция будет создавать при необходимости и возвращать админ он или нет.
Не ищите сложностей там где их нет.

Есть у меня подозрение, что не только пользователя проверяют при начале работы.
А нельзя ли всю работу загнать в одну функцию, чтобы она возвращала успешность запуска.
Тогда вызов сервера вообще будет один.

Вообще вопрос интересный. Не в контексте конечно темы, но вообще.

1С-ка не располагает к созданию каких-либо промежуточных слоев - сразу DB. Поэтому - запросы - первый инструмент 1С-ника. А запрос к DB инструмент дорогой, поэтому вместо того, чтобы считать объект Пользователь в память, а сам объект обвешать требуемыми функциями - 1С задается вопросом - сколько функций/запросов ему делать. В итоге никакой объектной модели нет, а вместо неё есть миллиард функций типа: АдминЛиЮзер(), аВчераОнБылАдмином(), аЕслиНеАдминТоКто() и так далее.

Вообще не представляю, как можно на 1С сделать поддерживаемую сложную систему (что-нибудь отличное от складского учета).

Что касается вопроса в теме - то подход неверен изначально.

Ибо функция

2) УзнатьАдминЛи(Пользователь);

является ничем иным как смешиванием уровня данных с уровнем алгоритмов. О каких паттернах тут вообще можно говорить - всё пишется жестко в коде.

Иэх...

(0) посмотри как в БСП сделано. 1 вызов сервера и сразу получает все необходимые параметры для продолжение работы или отказа.
СтандартныеПодсистемыВызовСервера.ПараметрыРаботыКлиентаПриЗапуске(Параметры);

(12) Объект "пользователь" можно считать в память, но он встроенный, и ничего в нём менять нельзя. Собственно, по этой причине почти во всех конфигурациях есть справочник "Пользователи", который потом пытаются синхронизировать с объектами "пользователи", что вносит ещё больше путаницы.
А у справочника мы можем сделать функции, которые будут вызываться в модуле объекта (экспортные), только у нас объект-то находится на сервере, и каждое обращение - вызов сервера.
Кстати, в любом Web-программировании с Ajax-функциями происходит точно тоже самое - с клиента вызывается сервер, только там это всё спрятано в код, и программист просто пишет вызов функции, не заглядывая внутрь. А в 1С между клиентом и сервером нельзя передавать объекты (только ссылки), вот и получается, что каждый программист должен вникать в цепочку, чтобы понять, почему вызов не удался.

Если на производительность существенно не влияет, то забей и сделай как тебе удобно.

(14)++