Файл утилит в php?
Ваш клиент использует Exchange 2007? Если так, я взглянул бы на веб-сервисы Exchange . В противном случае столь волосатый, как это может быть, я думаю, что WebDAV является Вашим лучшим выбором.
Лично мне не нравится использовать Outlook. Маршрут COM-объекта приложения, поскольку его безопасность запрашивает ("Приложение пытается получить доступ к Вашим контактам. Позволить это?", и т.д.), может вызвать проблемы на сервере. Я также думаю, что было бы трудно выполнить Ваши подобные олицетворению задачи с помощью Outlook, такие как отправка почты как данный пользователь.
3 ответа
Я всегда подходил к таким вопросам более прагматично.
Если вы хотите перейти на полностью ООП, вы, очевидно, должны вставлять их в классы. Однако эти классы будут только классами-контейнерами, потому что они на самом деле не представляют никаких объектов.
Также: использование классов потребует от вас либо наличия экземпляра этого класса, используя шаблон синглтона, либо объявления каждого функция статическая. Первый медленнее (ладно, может быть, не так уж и много, но в больших фреймворках такие вещи тоже становятся большими - особенно в интерпретируемых языках, таких как PHP), а второй и третий просто бесполезны и просто являются оболочкой ООП. для набора функций (особенно третьего подхода).
РЕДАКТИРОВАТЬ : Не стесняйтесь доказать, что я ошибаюсь. Я могу быть. Я не слишком опытен и всегда так считал,
Я всегда думаю о служебных функциях как о расширении стандартных функций php. Они не объектно-ориентированы, потому что вы не получаете никакой выгоды от их объектно-ориентированного использования.
Я стараюсь создать класс Util () , который содержит только статические методы, не имеет атрибутов и не наследуется от. По сути, он действует как «пространство имен» для множества служебных функций. Я позволю этому классу увеличиваться в размере, но иногда буду разделять методы на их собственные классы, если ясно, что эти методы предназначены только для работы с определенными типами данных или если ясно, что группа связанных методов должна быть сгруппированы в класс вместе с, возможно, некоторыми атрибутами.
Я думаю, что отклоняться от чисто ООП-методов вполне нормально, если код, который отклоняется, хорошо организован и не создает архитектурных недостатков в вашей системе, которые усложняют ее понимать и поддерживать.