Дата / Время и Интернационализация для корпоративных приложений - Руководство по разработке

Question

Вместе с другим разработчиком я отправился в путешествие по созданию размещенного приложения «Стиль CRM», которое будет обслуживать предприятия уровня предприятия.Эти компании будут получать доступ к нашему приложению удаленно, поэтому для размещения приложения потребуется определенная функциональность.Например, чтобы гарантировать уровень профессионального обслуживания, должны соблюдаться следующие условия:

• интернационализация требует нескольких языков и представления даты / времени для различных часовых поясов и локалей
• возможность транзакций дляпакетная обработка задач и возможности отката
• проблемы безопасности для обеспечения безопасности данных и защиты удаленных вызовов от атак
• и так далее, список можно продолжать и включать

Из-заЭти проблемы и моя роль разработчика, наиболее ответственного за разработку на стороне сервера, меня очень интересуют варианты, которые я делаю на раннем этапе.Что касается часовых поясов и языков, например, есть ли проблемы, связанные с моим выбором базы данных или полей данных?Я предпочитаю использовать метку времени UTC или поле даты во всем приложении, и если да, есть ли для этого стандартный формат?Кроме того, что касается разных языков, я должен гарантировать, что данные хранятся в базе данных как UTF-8 или Unicode?

Я действительно хочу избежать сложения структуры системы, но позже обнаружу, что фундаментальное решение было неправильным или недостаточно большим, достаточно широким, достаточно умным и т. Д. Может ли кто-нибудь указать мне правильное направление в отношенииэти базовые «ранние» решения?

EDIT _ Хорошо, я ценю широкие ответы, и теперь я вижу, что мой вопрос был слишком неспецифичным.Я хотел бы сосредоточиться на более конкретных элементах, которые БЫЛИ представлены в вопросе, таких как, как выбрать правильный формат для хранения даты / времени UTC или как сохранить мои текстовые данные (я указываю формат UTF?)

Answer 1

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

Короче говоря, основные принципы разработки программного обеспечения - ваш лучший выбор.

Answer 2

То, что вы обсуждаете, называется мультитенантным приложением, в котором используется одна и та же кодовая база, используемая несколькими клиентами (арендаторами) с логическим или физическим разделением данных. Помните фундаментальное правило развития: гибкость связана со сложностью. Чем гибче вы сделаете систему, тем сложнее она будет.

RE: UTC

Для приложения CRM, в котором хранятся такие вещи, как звонки и встречи, я определенно сохраню все в UTC и предоставлю пользователю возможность устанавливать местный часовой пояс. Тем не менее, вы можете столкнуться с датами, которые не зависят от часового пояса, и для них я буду хранить любую введенную дату.

RE: Unicode

Да, я бы использовал Unicode для всех введенных пользователем данных. Однако, вы не получите локализацию. Например, если для одной компании у вас есть пользователь в Гонконге, который вводит текст на китайском языке, и пользователь в Амстердаме, который вводит текст на голландском языке, вы не получите автоматический перевод. Такие вещи, как даты и числовые форматы, могут быть локализованы, но необработанный текст, такой как имена, используется в раскрывающихся списках и т. Д. Может быть трудной задачей для локализации.

Answer 3

Ничто не хранится как "юникод", потому что это абстрактное понятие. Unicode всегда хранится в каком-то формате преобразования Unicode (UTF) (ну или UCS, но я никогда не видел, чтобы это где-то использовалось). Наиболее часто используемым UTF является UTF-8, но я предлагаю использовать то, что является родным / по умолчанию для вашей платформы. википедии

Answer 4

Поскольку вы не упомянули, что вы думаете о проблеме, вы можете найти мой ответ или его части довольно простыми.

1. Если вам не нужно, не используйте язык низкого уровня. Я бы обычно использовал python для первой версии приложения CRM (с надеждой, что оно будет достаточно для следующих версий), но это решение зависит также от сообщества домена.
2. Попробуйте написать минимальный код самостоятельно, полагаясь на сторонние библиотеки. Люди могут не согласиться с этим, но я бы сам написал код в качестве последнего варианта. Но важен следующий момент.
3. При выборе библиотеки / фреймворка убедитесь, что вечеринка за ней продлится, библиотека стабильна и лицензия на программное обеспечение соответствует вашим потребностям.
4. Применяются и другие общие правила: сосредоточьтесь на клиенте, используйте непрерывную интеграцию / тестирование и т. Д., Используйте хорошие методы программного обеспечения, такие как ведение журнала и т. Д.