Skip to main content
OutSystems

OutSystemsプラットフォームのベストプラクティス

この記事では、OutSystemsプラットフォームを使用して開発を行う際に適用されるベストプラクティスや規則をまとめています。これらはあくまで推奨事項であり、それぞれの環境や開発スタイルに応じて調整する必要があります。

命名規則およびコーディング規約

標準言語

  • コードやコメントでは英語を使用する

命名規則

  • 意味がわかる名前(例: 「Cstr」ではなく「Customer」)
  • パスカルケースを使用する
  • 外部キーには「Id」というサフィックスを付ける(例: 「CustomerId」)
  • レコードの名前にはエンティティの名前を含める(例: 「record」ではなく「Customer」)
  • プレフィックスを使用して画面をグループ化する(例: 「Customer_Edit」、「Customer_Show」)
  • タイマーによって呼び出されるアクションには「Timer_」というプレフィックスを付ける
  • ShowRecords、EditRecords、TableRecordsのNameプロパティを設定する

コーディング規約

  • ラベルや説明を空にしない
  • わかりにくいロジックや複雑なロジックにはコメントを付ける
  • 式の文字列例を設定する
  • アクションフローは縦方向にし、整理する
  • ハードコーディングされた値の代わりに静的エンティティを使用する

再利用

  • ユーザーアクションを使用してロジックを再利用する
  • Webブロックを使用して画面の一部を再利用する
  • ユーザー関数を使用してデータの書式設定をカプセル化する
  • RefreshQueryを使用してクエリを再実行する

JavaScript、CSS、HTML

  • JavaScriptのカプセル化と再利用のためにWebブロックを使用する
  • JavaScriptブロックを完全に識別できるようにする
  • JavaScriptにコメントを付ける
  • ブラウザに依存しないJavaScriptを使用する(例: JQuery、mooTools)
  • エスケープされていない式を使用するカスタムHTMLの作成を避ける
  • CSSスタイルの重複を避ける
  • JavaScriptとCSSを極力少なくする 

データベース

  • 1つのエンティティに492個のアトリビュートは多すぎる可能性がある
  • サイズが4,000のアトリビュートは大きすぎる可能性がある
  • エンティティに対する外部キーの削除規則を確認する
  • Is Mandatoryプロパティを忘れずに設定する
  • エンティティには少なくとも説明を追加する

Aggregateおよび高度なクエリ

クエリ

  • Aggregate(最適化されていてデータベースに依存しない)を使用する
  • クエリ出力を繰り返す場合にインデックス([i])の使用を避ける
  • 実行する必要があるクエリの数を最小限にする
  • Aggregateでの型キャストを避ける

高度なクエリ

  • 高度なクエリは必要なときにのみ使用する
  • SQL内ではハードコーディングされた値の代わりにパラメータを使用するSQLコードは常にインデントする
  • SQL内でコメントやインラインコメントを使用する
  • 一括処理では高度なクエリを使用する
  • SQL内にビジネスロジックを配置しない
  • インラインパラメータにはEncodeSQLビルトイン関数を使用する
  • 高度なクエリはデータベース固有であることに留意する

変化に対応した構築

  • 高度なクエリよりAggregateを優先する
  • 高度なクエリはメンテナンスしにくいことに留意する
  • カスタムHTML/JavaScriptの作成を避ける
  • 異なるWeb画面で機能を分ける
  • 拡張機能を使用してビジネスロジックを実装しない

ユーザーインターフェイス

  • JavaScriptブロックは画面の最後に移動する
  • ユーザーを観察してどのような改善が必要であるかを確認する
  • 通常、ノード数が10を超えるPreparationではトラブルが発生する
  • eSpaceの画像のサイズを小さくする

アーキテクチャ

  • 3レイヤーアプローチを使用する
    • ビジネスプロセス: ユーザープロセスやビジネスプロセスで使用できるサービス
    • コアエンティティ: 役割に基づく論理的なオペレーショングループ
    • コネクタ: 拡張機能または他のシステムとの連携
  • 拡張機能をeSpaceにラップする
  • eSpace間の循環参照を避ける
  • 各eSpaceの役割を明確に定義する
  • 使用していない参照を削除する ビジネスロジックをユーザーアクションでカプセル化する
  • ユーザーストーリーに沿ったインターフェイスを作成する 1つのeSpace内のデータモデルを分離しない eSpaceはアーキテクチャ単位ではなく機能単位にする
  • できるだけ非同期ロジックを使用する
  • OutSystemsアーキテクチャの設計技術

キャンバス画像

チーム作業

  • プロジェクトに対する推奨プロジェクトチームを把握する(「OutSystemsプロジェクトのスタッフ配置」を参照) [1]
  • チームメンバーごとに単一のユーザーを使用する
  • チームメンバー全員が同じService Studioバージョンを使用する
  • LifeTimeを使用してアプリケーションのバージョン管理を行う
  • 単一のeSpaceのパブリッシュを避ける: LifeTimeを使用する
  • 同時に同じ要素で作業することは避ける
  • チームプロセスを作成し、積極的なログ監視を実行する
  • チームプロセスを作成し、データ更新スクリプトなどの手動デプロイ手順を実行する
  • 「完了」の意味を定義し、テストを含める

ロジックおよび開発

  • 使用していないコードや重複しているコードを削除する
  • 通常、4 MiBを超えるサイズのeSpaceは不適切なアーキテクチャとなる
  • Web画面にはデフォルトボタンを1つ以上設定する
  • ロジック内でサイトプロパティの値を変更することは避ける
  • 無限再帰に注意する
  • 正当な理由がある場合のみ警告を非表示にする
  • 通常、1つのeSpaceで20を超えるサイトプロパティは不適切な設計となる
  • Webサービスの利用のためだけに拡張機能を使用することは避ける
  • 本番環境では拡張機能の監査を無効にする

セキュリティ

  • Web画面のロールを設定する
  • 機密データの交換に注意する
  • 機密情報を画面パラメータで送信しない
  • Web画面の変数やPreparationの出力はURLやビューステートで公開される可能性があることに留意する
  • 可能な限り、機密情報にはSSLを使用する
  • 権限のコントロールに、Web画面ウィジェットのインターフェイスを利用しない
  • 画面アクションの実行前にユーザーのロールを検証する
  • データベース内では暗号化されたパスワードを使用する
  • 内部アクセスはWebフローおよびWebサービスでのみ使用する 

パフォーマンス

データモデル

  • エンティティのインデックスを作成する
  • 大きいテキストデータやバイナリデータは別のエンティティに分離する
  • 大きいExcelファイルのパフォーマンスに注意する
  • エンティティで削除規則を活用する
  • 古いデータを別のエンティティにアーカイブする

インフラ

  • データベースの保守計画を立てる
  • Webサーバーのメモリ設定を構成する
  • データベースのトランザクションログをこまめにバックアップする
  • データベースファイルの増大を調整する
  • 仮想メモリとシステム設定を適用する
  • タイマーには専用サーバーを使用する
  • 64ビットアーキテクチャを優先する
  • 衝突が発生しないようにタイマーのスケジュールを計画し、監視する

ロジック

  • Service Centerのレポートを調査する
  • タイマーおよびバッチジョブの長期実行を避ける
  • 画面のPreparationを簡素化する
  • セッション変数内に配置する情報はできるだけ少なくする
  • ユーザーアクション内で分離されたAggregateを使用することは避ける
  • PreparationのIfブランチ内でクエリを使用することは避ける
  • 連鎖したWebサービスの呼び出しを避ける単一の呼び出しでできるだけ多く返す

クエリ

  • リンクされた複数のサーバーにまたがる結合を実行しない
  • データベースから取得するフィールドの数を最小限にする
  • 最大レコード数は常に必要数に合わせる
  • クエリは1回繰り返し、インデックス([i])の使用を避ける
  • 実行クエリ数を最小限にする

参照

  • eSpace間の循環参照を作成しない
  • ローカルWebサービスとパブリックアクションを適切に選択する
  • 接続プーリングを使用する

ユーザーインターフェイス

  • 画面アクションでPreparationデータを使用することは避ける
  • Ajaxは慎重に使用する - 全体的なパフォーマンスに影響する場合がある
  • 複雑なWeb画面を1つ作成するのではなく、複数のWeb画面を使用する
  • キャッシュを活用する
  • 画面パラメータを最小限にする
  • JavaScriptファイルをリソースとしてインポートする
  • 読み込み時に不要なJavaScript Webブロックは一番下に移動する
  • CSSスプライト画像を使用する

一般的なパターンおよび例

例として、使用または参照できるオープンソースアプリの一覧を以下に示します。

開発時間を短縮するためにコンポーネントをダウンロードするには、Forgeをご覧ください。 [2]

他の学習リソースについては、OutSystemsの「Training」セクションをご覧ください。 [3]