11月17日（木）3、4コマ目

今日、やったこと

  • 例外(C#)のサンプルアプリケーション
  • 例外(C#)の練習問題

今日のホワイトボード

サンプルアプリケーション

前回の続きです。

前回はDBアクセス部分を実装しました。

前回、お伝え忘れていました。戻り値で結果を伝える際、

  • 1なら成功
  • 2はxxxエラー
  • 3はxxxエラー

のようにマジックナンバーで伝えるのはやめてください。

戻り値からなにが起きたかわからないです。

図　マジックナンバーはやめて


今回は画面周りです。

Index.cshtml.cs

入力チェックをしています。本来なら未入力エラーはリカバリしてほしいエラーなので、戻り値で伝える必要があります。が、if()のネストが深くなる、すでにtryブロックがある、ことから例外スローで通知しています。


Index.cshtml

ここは特に問題ないかと。

ちなみに未入力チェックや入力内容チェックはHTMLでもできます。


C#での入力チェック

stringクラスにはnullまたは空白文字列をチェックするメソッドがあります。

図　null、空白チェック


次回は

今回、作ってもらった”[練習問題]パスワード変更"の解説と評価用課題を出します。 

このブログの人気の投稿

11月14日（月）1、2コマ目

イメージ
今日、やったこと 例外（C#) 今日のホワイトボード 処理終了時の状態 処理終了時は 正常終了 異常終了 の２つに分かれます。 さらに、異常終了も 想定内のエラー 想定外のエラー の２つに分かれます。 エラーを「想定内」、「想定外」 分けていますが、「想定外」なエラーもよく考えれば「想定内」なエラーになります。 ここで、エラーの内容を以下のように再定義します。 「想定 内 のエラー」は 利用者にエラー発生を伝えて、リカバリをしてほしい エラー。 「想定 外 のエラー」は 利用者に通知してもしょうがない エラー。 図　想定内のエラー、想定外のエラー 処理結果をどうやって伝える 処理(メソッド)の結果は 〇ユーザーに通知してリカバリしてほしいエラー 　 戻り値で通知 〇ユーザーに伝えてもしょうがないエラー 　 例外スローで通知 図　結果を伝える方法 ただし、 この方針は絶対的なものではありません 。 しかし、この授業では今後この方針でいきます。 戻り値は 結果が 成功 失敗 の2種類ならbool型へ。 処理結果の状態が3つ以上なら列挙型(enum型)で。 図　戻り値のつかいわけ 例外スロー時の対応 やってはいけない ことは 　 例外をキャッチしてもなにもしない(catchブロック内が空) です。 基本的に、例外がスローされたら そこで処理は中断 呼び出し元へエラー発生を通知（例外スロー） ...
続きを読む

10月27日（木）3、4コマ目

今日、やったこと [練習問題]C#＋コミット・ロールバック  今日のソースコード 正解例をあげておきます。 Startup.cs セッションなし。いつもどおり。 Item.cs プロパティ＋コンストラクタのクラス。いつもどおり。 ItemDAO.cs Update()メソッドがポイントでしょうか。 Index.cshtml.cs OnPost()メソッドがポイントでしょうか。 基本的な流れは以前Javaでやった同じ仕様の練習問題と同じです。 Index.cshtml とくにややこしいことはないかと思います。 次回は 今日の練習問題の解説とロックの練習問題です。
続きを読む

10月4日（火）1、2コマ目

イメージ
今日、やったこと トランザクション 今日のホワイトボード トランザクションとは 1件の処理＝１トランザクション。 たとえば、送金処理とか在庫更新とかで１つのトランザクション。 １つのトランザクションには複数のSQLを実行するケースが多い。 トランザクションに必要な要件 ACID特性が必要。 Atomicity（原子性） Consistency（一貫性） Isolation（独立性） Durability（永続性） トランザクションの原子性 トランザクション終了時には 全ての更新を実行 まったく更新をしていない のいずれかでなければならない。成功した更新と失敗した更新が存在するのはNG。 図　トランザクション終了時の状態 トランザクションの原子性はコミット、ロールバックで実現。 図　コミット、ロールバック トランザクションの独立性 トランザクションは単独で実行しても、複数同時に実行しても結果は同じでなければならない。 図　複数トランザクションが同時に実行されると そのために、トランザクション同士を分離、独立させて実行し、互いに影響が及ばないようにする。 このトランザクションの分離レベルが全く分離しない（Read Uncommitted)からほぼ完ぺきに分離する（Serializable）まで4段階ある。 この分離レベルに応じて、他トランザクションにいろいろな影響（ダーティーリード、ファジーリード、ファントムリード）が発生する。 ダーティーリード 他トランザクションで、更新したがコミットしていないデータを参照してしまうこと。 図　ダーティーリード 多くのDBの分離レベルはRead Committedなので、ダーティーリードは発生しない。 Read Committedなら、非コミットデータは参照しない。 ファジーリード 同じデータを参照しても、他トランザクションが更新することで、毎回異なるデータを参照すること。 分離レベルがRead Committedなら、コミットしたデータは参照できるため、ファジーリードが発生する。 ファントムリード 他トランザクションが追加、削除することで、参照するたびに出力行数が異なること。 分離レベルがRead Committedなら、コミットしたデータは参照できるため、ファントムリードが発生する。 ロック DB更新時には更新対象行をロックして、...
続きを読む