- バックアップ一覧
- ソース を表示
- OpenSaaS1ExecEngineの開発で検討したこと。 は削除されています。
.NET 開発基盤部会 Wiki
目次 †
概要 †
OpenSaaS1ExecEngineの開発で検討したこと。
Tablet系 †
専用端末化 †
- Android/iOS両方で実現可能。
- ただし，OSバージョン縛りがあるので(特にAndroidは)要注意。
Android †
Android 5.0から追加された「画面の固定」機能を使えばアクティブなアプリを限定できる。
iOS †
iOS6から追加された「Single App Mode」が使える。
HTML系 †
オフライン †
- オンライン環境でない場合に、オフラインで動作する方法を検討する。
- 実装はHTML（HTML5）のWeb技術を使用する（スマホ・ネイティブ解らんので）。
- オフライン時にlocal-Storageに溜め込んでバッチ送信みたいなことを考えている。
- 色々考え、処理系を切り替える必要があるので結構難しそうだと感じた。
- 切り替えが面倒なので、一律、
- ローカルストレージに蓄積
- 定期的な情報送信を行う。
という方式が良いと考えた。
チェック †
window.navigator.onLineでチェック可能。
ポピュラーな、Key-ValueのWebStorageが良さそう。
定期的な情報送信 †
setTimeoutやsetIntervalなどを用いることで実現できる。
最新の「Web Workers」については、別に使用しなくていもイイかな。という感想。
JSON処理 †
- サーバー側（WCF）
web.configの書き方が間違っていると動かないので注意。
web.configの書き方は、下記のosscons.jpのマイクロソフト系技術情報 Wikiが参考になる。
成功と失敗 †
- WebAPIの戻り値での判断は、二重登録の可能性があり、少々危険だと考える。
- トランザクションが成功した後にHTTPでエラーになると二重登録になる。
- HTTPで成功した後に、local-Storageのクリアに失敗した場合も、二重登録になる。
- 上記の二重登録の問題を解決するために、レコードにIDを付与する。
- 店舗ID + 端末ID + 時間 ( yyyy/MM/dd HH:mm:ss SSS )
- 店舗ID : ユーザアカウントから取得可能。
- 端末ID : HTMLから取得する方法が無い。
- 時間 : dateformat.jsを使用して取得可能。
スキーマ †
- 分割キー（企業ID）は、
- クラスタ化キーか、
- パーティション分割列か、
- シャーディング・キーか、
に使用する。
マスタ・データ †
企業テーブル †
店舗テーブル †
端末テーブル †
ユーザ・テーブル †
画面表示情報テーブル †
- 画面の表示に必要になる情報
- 画面テンプレート・画面表示情報を結合して画面を生成する。
- 画面表示の前に、店舗ID・端末ID（不足の情報）を指定する。
- 非構造化データ（JSON）
画面によって構造が異なるので、
- コントロールに関する情報を非構造化データに格納する。
- 非構造化データのフォーマットにはJSONを採用する。
- JSONのテンプレートは、画面ID（GUID）毎にweb.configに仕込んでおく。
画面表示情報を作成するときは、このJSONテンプレートをベースにする。
以下、画面表示情報の項目情報。
- 共通
- ID
- 分割キー（企業ID）
- 画面ID（GUID）
- 有効期限（履歴）
- 画面タイトル
- 追加の検索条件情報
追加の検索条件情報として登録する、
下記の非構造化データ（JSON）の
値のキー情報を登録しておく。
画像テーブル †
- ID
- 分割キー（企業ID）
- 店舗ID（オプション）
- 端末ID（オプション）
- 画像データ（バイナリ）
トランザクション・データ †
結果 †
- 追加の検索条件
DBMSスキーマ上にあれば、集計処理で検索条件として使用できる。
例えば、非構造化データ（JSON）中の以下の項目を検索条件として追加する。
画面 †
コンテンツ画面 †
HTML/CSS/JavaScript技術を中心に使用して開発する。
カスタマイズ画面 †
エンプラ寄りのWeb Forms技術を中心に使用して開発する。
非構造化データ（JSONデータ）の入力・編集処理 †
- 非構造化データ（JSONデータ）の入力・編集処理の簡略化がキーポイント
- 画面の自動生成も面倒なので、JSONの生データを編集する方式にする。
- ・・・と考えていたが、リテラシのバラつきにより、
エンドユーザにはハードルが高いケースがあるらしいので、
JSONのキー情報から、入力項目を自動生成する方向性に変更。
- 入力・編集を行うときは、入力フィールドを自動生成する。
- ユーザが入力・編集（= 入力フィールドを自動生成）する項目かどうか？
を、JSONのキー情報のプレフィックスから判断する方式にする。
- このプレフィックスを事前に決めておく事が必要になる。
条件検索画面 †
エンプラ寄りのWeb Forms技術を中心に使用して開発する。
条件検索と集計・グラフ表示機能 †
- 集計処理
- 集計対象 : ボタンID（GROUP BY ボタンID）
- 集計関数 : COUNT(*)
上記を踏まえた技術選定 †
Open棟梁はコミュニティ連携のため前提で（笑）。
OS †
Windows †
DBMS †
PostgreSQL †
- スタートアップで人気。
- MosPで運用実績がある。
WAS †
IIS+ASP.NET †
.NET開発基盤部会だけに。
フレームワーク †
画面毎 †
- 基本
- ASP.NET Web Forms ( HTML サーバー コントロール )
- WCF ( DataContractJsonSerializer? )
- Ajax( jQuery )
- ADO.NET.
- 若しくは
- ASP.NET MVC
- ASP.NET Web API
- Ajax( jQuery )
- ADO.NET.
- その他の画面
- 特徴
- フレームワーク
- ASP.NET Web Forms ( ASP.NET Web サーバー コントロール )
- ADO.NET.
ASP.NET Web Forms †
ASP.NET Web Formsを選択した。
- ASP.NET MVCであっても・なくても良かった。
- 赤波線の件と、
- コントロールのキャプション置換がWeb Formsの方が楽だと思ったから。
- グラフ表示画面もあるので、ChartControlを使いたいと思ったから。
- B・D層を別DLL化して、必要ならUIサブシステムだけMVCに切替えるのはアリだと思う。
Ajax - REST ( JSON ) - WebAPI †
Web Formsだが、オフライン実装を考慮しPostBack?無しのWebAPIで実装。
- フレームワーク
- Ajax ( jQuery )
- REST ( REST JSON )
- WebAPI ( WCF ( DataContractJsonSerializer? ) )
ADO.NET †
ADO.NETでイイと考えた。
,etc. †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
