QandAAnalysisEngineの開発で検討したこと。のバックアップ(No.3) - .NET 開発基盤部会 Wiki

[ トップ ] [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

.NET 開発基盤部会 Wiki

戻る

覚書(TODO) †

SQL †

集計
- http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1114025801

画面 †

集計
編集
サイン・アップ

フラグ初期化タイミング †

ログイン
- EnterprisesID
- StoresID
画面生成
- DevicesID
- InitializeScreenInfoID

目次 †

覚書(TODO)
目次
概要
Tablet系
- 画面サイズ
- 専用端末化
HTML系
業務系
- サイン・アップ
テーブル
画面系
上記を踏まえた技術選定
本開発
- 画面
- テーブル
- SQL
プロト開発

概要 †

QandAAnalysisEngineの開発で検討したこと。

Tablet系 †

画面サイズ †

4：3（16：10）が主流

よく使うメディアサイズとデバイスの縦横比〜なぜiPadは4：3なのか | 楽しく生きたいです
http://fun.hypoes.com/2014/06/ipad43.html

本SaaSはTablet横置きになる。
- 16（横）：10（縦）に合わせて
- 16（横）：9（縦）の場合、横を％指定のレスポンシブで広げて対応。

専用端末化 †

HTML系 †

オフライン †

オンライン環境でない場合に、オフラインで動作する方法を検討する。
実装はHTML（HTML5）のWeb技術を使用する（スマホ・ネイティブ解らんので）。
オフライン時にWebStorageに溜め込んでバッチ送信みたいなことを考えている。
色々考え、処理系を切り替える必要があるので結構難しそうだと感じた。
切り替えが面倒なので、一律、
- ローカルストレージに蓄積
- 定期的な情報送信を行う。

という方式が良いと考えた。

チェック †

window.navigator.onLineでチェック可能。

window.navigator.onLine - Web API インターフェイス | MDN
https://developer.mozilla.org/ja/docs/Web/API/NavigatorOnLine/onLine

ストレージ †

ポピュラーな、Key-ValueのWebStorageが良さそう。
スコープの関係から、WebStorageのSession-Storageを選択。

定期的な情報送信 †

バック・グラウンド処理 †

setTimeoutやsetIntervalなどを用いることで実現できる。
最新の「Web Workers」については、別に使用しなくていもイイかな。という感想。

JSON処理 †

クライアント側（JavaScript）

サーバー側（WCF）
web.configの書き方は、下記のosscons.jpのマイクロソフト系技術情報 Wikiが参考になる。
- JSONを送受信するRESTサービスを作成する方法 - マイクロソフト系技術情報 Wiki
  
  web.configの書き方が間違っていると動かないので注意

成功と失敗 †

WebAPIの戻り値での判断は、二重登録の可能性があり、少々危険だと考える。
- トランザクションが成功した後にHTTPでエラーになると二重登録になる。
- HTTPで成功した後に、Session-Storageのクリアに失敗した場合も、二重登録になる。

上記の二重登録の問題を解決するために、レコードにIDを付与する。

GUID
- 長過ぎる。
- ライブラリが無い。

店舗ID + 端末ID + 時間 ( yyyy/MM/dd HH:mm:ss SSS )
- 店舗ID : ユーザアカウントから取得可能。
- 端末ID : HTMLから取得する方法が無い。
- 時間 : dateformat.jsを使用して取得可能。

動作
- クライアント側
  - 成功時
    Session-Storageのクリア
  - 失敗時
    Session-Storageをクリアしない（リトライ）

サーバー側動作
- 成功時
- 失敗時

エフェクト †

効果音 †

アニメーション †

二重クリックの防止 †

マスク掛け
マスク解除（setTimeout）

上記だけでは無理だったので、
クリック後に変更される変数値を確認する実装とした。

業務系 †

サイン・アップ? †

テーブル †

画面系 †

上記を踏まえた技術選定 †

Open棟梁はコミュニティ連携のため前提で（笑）。

OS †

Windows †

特に、Linuxである必要を感じなかった。

DBMS †

PostgreSQL †

スタートアップで人気。
MosPで運用実績がある。

データプロバイダ
- ADO.NETデータプロバイダ - マイクロソフト系技術情報 Wiki
  - PostgreSQL

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.

その他の画面
- 特徴
  - エンプラチックな画面
  - グラフ表示画面でChartControlを使用したい。
- フレームワーク
  - ASP.NET Web Forms ( ASP.NET Web サーバーコントロール )
  - ADO.NET.

全体的に
- Entity Frameworkは個人的に、パス。

ASP.NET Web Forms †

ASP.NET Web Formsを選択した。

HTMLに準拠した実装がし易いように、HTML サーバーコントロールを使用する。

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でイイと考えた。

簡単なクエリのみ。
一々、Entity Framework使う程でもない。
複雑なエンプラの方がハマらないのだっけ？
あまりピンとこない、Beanを永続化するならNoSQLでイイのでは。

,etc. †

本開発 †

画面 †

テーブル †

SQL †

プロト開発 †

Ph1 †

3 画面

コンテンツ画面 †

種々の情報は固定

集計画面 †

集計画面１
円グラフ／ドーナツ・グラフで結果を表示する。
集計画面２
積み上げ棒グラフで期間毎の結果（の変化）を表示する。

Ph2 †

6 画面追加

3 テーブル * CRUD画面は 2 画面（検索・詳細） = 6 画面

メンテナンス画面の追加 †

画面テーブルのCRUD画面
画像テーブルのCRUD画面
画面初期化情報テーブルのCRUD画面（ユーザ）

コンテンツ画面 †

種々の情報を可変に。

Ph3 †

8 画面追加

4 テーブル * CRUD画面は 2 画面（検索・詳細） = 8 画面

メンテナンス画面の追加 †

ユーザ・テーブルのCRUD画面
企業テーブルのCRUD画面
店舗テーブルのCRUD画面
端末テーブルのCRUD画面

コンテンツ画面 †

サイン・イン、サイン・アウト（認証）に対応