１０月５日、JSUG勉強会 ２０１６年その８～今から始めるSpringに言ってきたので、その内容をメモメモ・・・するんだけど、
もう、ちゃんとしたメモがネットにでていた
「JSUG勉強会 2016年その8 ～ 今から始めるSpring」に行った
http://qiita.com/y_q1m/items/d8e12d5ad1b7b71aeef5
ので、ちゃんとしたいのが見たい人はそちら！
（ここのメモは、ろりぽじさんんIT用語説明レベルのアバウトさ＝雰囲気レベルです）・・・
なので、ここでは、最後に「所感」を書いておこう！
■DI/AOPについて学んでみた
・自己紹介
・会社紹介（TIO）
・Springと私
基礎知識なしでなんとなく使っていたレベル
インターフェース、applicationContext.xml
右に倣え
・なぜ
DI/AOPを調べれば分かるよ
・DIについて調べてみました
概要
依存性の注入：外部の設定ファイルなど※
※ApplicationContext.xml アノテーションで設定
メリット
結合性低下によるコンポーネント化の促進
単体テストの効率化
手法
インターフェース注入
Setter注入など
・DIとは（イメージ）
class Service 利用:Dao class DaoImple
注入 で異性
DIコンテナ
参照
ApplicationContext.xml→依存関係を定義
→newすることがなくなる
・これっておいしいの
脳内アプリ；会員サイトの検索機能
イメージ：ブラウザ→アプリケーション→DB
登場クラス
Action
サービス
DAO
user：値格納・情報返却
・DIを使わない構成
利用する側のクラスが必ずnewする→密結合
利用する側・される側が密結合している
・DIを使った構成
DIコンテナで生成して利用する側に注入する
利用する側、される側が疎結合になっている
DIコンテナ→ApplicationContext.xml
・で、メリットは
クラスの関係が疎結合
変更に対応しやすい
試験を実施しやすい
固定された値でテスト
・AOPについてしらべてみた
本来すべき処理とすべきでない処理
本来すべきではない処理をあとから呼びだす
・AOPを使った場合と使わない場合の確認
AOPを使う→トランザクション管理クラスを作る
本来すべきではない処理の実装ミスを防げる
一元管理できる
処理を変更せずに後から追加できる
・まとめ
SpringにはDI/AOPを利用する機能が備えられている
疎結合ナシステムを構築できる
■Springをなんとなく使っている人が抑えるべきポイント
・自己紹介
・概要
Springｗ９おなんとなく使っていませんか
上手く動かないときの対応ができない
応用が利かない
面白くない
主要なポイントを抑えて、開発を面白くしましょう
・主要なポイント
Beanのコンフィギュレーション：３通りある
DI/AOPの使いどころ
データアクセス
・コンフィグレーションの方法
３種類選べる：結果は同じ
XML
アノテーション @Compornemt
JavaConfig @Bean
→DIコンテナが管理するオブジェクトをBeanと呼ぶ
XML
メリット：分離できる。一元的に管理、再ビルド不要
デメリット：メンテが大変
アノテーション
メリット；記述が楽
デメリット：プログラムとBeanの定義が混在
JavaConfig
メリット：分離できる、タイプセーフ
デメリット：メンテが大変
一般的と思われる使い分け
業務個別のBean(コントローラー、サービス、Dao)はアノテーション
裏方のBeanはXMLまたはJavaConfig
→そもそも、アノテーションが付けられない
・DI/AOPの使いどころ
DI：すべてをBeanで管理するわけでない
ステートレスなオブジェクト（コントローラー、サービス、Dao）
→BeanにしてDIで紐付け、ASOP
処理のたびにオブジェクトが生成され、個別のフィールド値を設定する
Entity,DTOはBeanにしない
AOP：
レイヤー間にAOPで共通処理（BeanにしかAOPできないという事情も）
業務的な処理は基本的にAOPは使わない
→わかりにくくなる（例：税率かける）
・同じオブジェクトが使われている
リクエストのたびに、コントローラー、サービス、Daoのオブジェクトが
作成されるわけではない
リクエスト間でデータ共有（キャッシュ）
スレッドセーフにする必要
・インターフェースは必須じゃない
インターフェースを介さなくてもDIは可能
用途の例：各レイヤーの補助的なBean
・コネクション・トランザクション周りの仕組み
トランザクションの開始・終了はSpringが行う
ソースは書かなくていい
画面周りの処理の流れ
Dispatcher Servlet
HandlerMapping：コントローラー特定
HandlerAdapter：引数の値を用意
ViewResolver：Viewの形式ファイルを特定
コントローラー
モデル
View
・認証・認可の仕組み
認証とURLの認可はServletFilterで行われている
DispacherServletに依存していない（SpringMVCに依存しない）
認可の主な対象はURL、メソッド、画面描画の３種類
認証のサーブレットフィルターなど
セキュリティコンテキスト：HTTPSession.ThreadLocalなど
SpringMVCを使わなくても使える
・サーバーを起動しなくてもBeanをテストできる
@before
public void setup()
{
ApplicationContext ctx = new AnnotationConfigApplicationContext(TestConfig.class);
fooserve = ctx.getBean(Fooservice.class);
・Spring Bootが行っていること
必要なJarファイルのダウンロード、
Beanのコンフィグレーション、
サーバーの実行
業務固有のBeanのプログラムつくりは変わらない
組み込みじゃないTomcatにデプロイ可能
・最後に
おすすめ
改訂新版Spring入門
Spring徹底入門
■悩めるJava初心者のためのSpringをどーんとやってみよう
「よい子・悪い子・普通の子」
・自己紹介
よい子のやまざきさん
普通の子 ときさん
わるいこ てらひでさん
・どうやってSpringを勉強したか
よい子
仕事で使うのが一番！SpringOne
苦労：良くも悪くもドキュメントが豊富
普通の子
本を読んで独学。Springを使う開発現場がなかった
わるいこ
勉強などしていない。
勉強しなくても使えるフレームワークがよいフレームワーク
苦労したこと：仕事にならない
・事前に勉強することはあるか
JSP-Servlet、DDDとか
よい子
Reactive！
普通の子
Java文法（例外などのややマイナー部分）
DBまわり、Webまわり、JSP-Servlet、JUnit
→ローカル変数の生成と消滅
わるいこ
男気のある優しい先輩の見分け方
たばこをすうか、おさけをのむか
姉御みたいなひと
→会社にいますか？
バージョンは６の人は
よいこ
８にする
普通の子
わるいこ
いいんだよ、すごくいいんだよ
→８にあげられない場合は
わるいこ：８に使える現場にうつる
Spring初級者になるための勉強範囲は
よいこ
・だめだ、全部だ、ドキュメント全部読め
ふつうのこ
・データアクセス、トランザクション、SPりんｇMVC
わるいこ
・難しいことは全部Springがやってくれる
初心者にぜひ理解してほしいこと、１つ上げるとしたら何
よい子
理解して使うこと！なんとなくでは、正しく動いてないぞ
普通の子
newが１つもなくなるわけではない
だめなこ
Springは開発者が仕事をサボる生産性をあげるための
便利な道具
SpringBootから勉強するのはあり
よいこ
いいんじゃないか。興味を持つため
ふつうのこ
おすすめはしない。何が起こっているかわからない
わるいこ
超おすすめ。Gradle最高！
初級者・中級者になったことは、どう確認すればよいか
よいこ
システム作って、誰かに売る
普通の子
すう画面のWebアプリを自分で設計・実装して、上級者に見てもらう
悪い子
GitHubにソースコードを公開してTwitterで自慢する
発表するのはどのレベル
よいこ
いつでも
普通の子
いつでも
悪い子
難しいことをする前に、ビアハッシュでLTだ
最後の一言
よいこ
JSUGに参加しましょう
普通の子
本を買って・・・
悪い子
こまったら、つぶやく
SpringDay2016
１１月１８日
すごいセッション
全て無料、懇親会、LT
■所感
DIの「依存性」や「AOP」などはソフトウェア工学から来ている用語だと思う。
なので、そこから入らないと、？？？になってしまう。
たとえば、AOPのとことで、「本来すべきでない処理」のところで、
ログ処理が入っているのはいいとして、
「トランザクション処理」は、どうなのどうなの？
いや、それは、しなきゃだめな子な処理でしょ！
これは、「横断的関心事」というソフトウェア工学の概念を
テキトーに言い換えてしまったから起こることで、
ソフトウェア工学的に言うと、
処理は
その機能内で閉じて考えてすべき処理（局所化すべき処理）
その機能内で閉じて考えず、（横断的に考えて）すべき処理（横断的関心事）
にわけられる。
前者は、機能要件で記載されるもので、受注なら受注、発注なら発注のオブジェクトが
担当するというように、担当するオブジェクトが決められ、そのオブジェクトが、他オブジェクト
を監視・制御することで、処理が決定できる。
後者は、主に非機能要件で議論されるもので、受注・発注のみならず、横断的に
調停するオブジェクトが必要となるものである。これが横断的関心事
たとえば、トランザクションは、受注・発注・取引先など、いくつもの機能に
同時にかかわり、矛盾ないように調停しないといけない。これが横断的関心事
ログも、受注と発注が別々だと、わかりにくい（時間がずれてたりすると、
前後関係不明になる）
このほかには、セキュリティなどがある（受注はセキュリティばっちりだけど、
発注はザルとかだと、意味ない）
Diについても、ソフトウェア工学的に、背景がある（文脈＝コンテキスト）
そのへんについては・・・いつか、かく
もう、ちゃんとしたメモがネットにでていた
「JSUG勉強会 2016年その8 ～ 今から始めるSpring」に行った
http://qiita.com/y_q1m/items/d8e12d5ad1b7b71aeef5
ので、ちゃんとしたいのが見たい人はそちら！
（ここのメモは、ろりぽじさんんIT用語説明レベルのアバウトさ＝雰囲気レベルです）・・・
なので、ここでは、最後に「所感」を書いておこう！
■DI/AOPについて学んでみた
・自己紹介
・会社紹介（TIO）
・Springと私
基礎知識なしでなんとなく使っていたレベル
インターフェース、applicationContext.xml
右に倣え
・なぜ
DI/AOPを調べれば分かるよ
・DIについて調べてみました
概要
依存性の注入：外部の設定ファイルなど※
※ApplicationContext.xml アノテーションで設定
メリット
結合性低下によるコンポーネント化の促進
単体テストの効率化
手法
インターフェース注入
Setter注入など
・DIとは（イメージ）
class Service 利用:Dao class DaoImple
注入 で異性
DIコンテナ
参照
ApplicationContext.xml→依存関係を定義
→newすることがなくなる
・これっておいしいの
脳内アプリ；会員サイトの検索機能
イメージ：ブラウザ→アプリケーション→DB
登場クラス
Action
サービス
DAO
user：値格納・情報返却
・DIを使わない構成
利用する側のクラスが必ずnewする→密結合
利用する側・される側が密結合している
・DIを使った構成
DIコンテナで生成して利用する側に注入する
利用する側、される側が疎結合になっている
DIコンテナ→ApplicationContext.xml
・で、メリットは
クラスの関係が疎結合
変更に対応しやすい
試験を実施しやすい
固定された値でテスト
・AOPについてしらべてみた
本来すべき処理とすべきでない処理
本来すべきではない処理をあとから呼びだす
・AOPを使った場合と使わない場合の確認
AOPを使う→トランザクション管理クラスを作る
本来すべきではない処理の実装ミスを防げる
一元管理できる
処理を変更せずに後から追加できる
・まとめ
SpringにはDI/AOPを利用する機能が備えられている
疎結合ナシステムを構築できる
■Springをなんとなく使っている人が抑えるべきポイント
・自己紹介
・概要
Springｗ９おなんとなく使っていませんか
上手く動かないときの対応ができない
応用が利かない
面白くない
主要なポイントを抑えて、開発を面白くしましょう
・主要なポイント
Beanのコンフィギュレーション：３通りある
DI/AOPの使いどころ
データアクセス
・コンフィグレーションの方法
３種類選べる：結果は同じ
XML
アノテーション @Compornemt
JavaConfig @Bean
→DIコンテナが管理するオブジェクトをBeanと呼ぶ
XML
メリット：分離できる。一元的に管理、再ビルド不要
デメリット：メンテが大変
アノテーション
メリット；記述が楽
デメリット：プログラムとBeanの定義が混在
JavaConfig
メリット：分離できる、タイプセーフ
デメリット：メンテが大変
一般的と思われる使い分け
業務個別のBean(コントローラー、サービス、Dao)はアノテーション
裏方のBeanはXMLまたはJavaConfig
→そもそも、アノテーションが付けられない
・DI/AOPの使いどころ
DI：すべてをBeanで管理するわけでない
ステートレスなオブジェクト（コントローラー、サービス、Dao）
→BeanにしてDIで紐付け、ASOP
処理のたびにオブジェクトが生成され、個別のフィールド値を設定する
Entity,DTOはBeanにしない
AOP：
レイヤー間にAOPで共通処理（BeanにしかAOPできないという事情も）
業務的な処理は基本的にAOPは使わない
→わかりにくくなる（例：税率かける）
・同じオブジェクトが使われている
リクエストのたびに、コントローラー、サービス、Daoのオブジェクトが
作成されるわけではない
リクエスト間でデータ共有（キャッシュ）
スレッドセーフにする必要
・インターフェースは必須じゃない
インターフェースを介さなくてもDIは可能
用途の例：各レイヤーの補助的なBean
・コネクション・トランザクション周りの仕組み
トランザクションの開始・終了はSpringが行う
ソースは書かなくていい
画面周りの処理の流れ
Dispatcher Servlet
HandlerMapping：コントローラー特定
HandlerAdapter：引数の値を用意
ViewResolver：Viewの形式ファイルを特定
コントローラー
モデル
View
・認証・認可の仕組み
認証とURLの認可はServletFilterで行われている
DispacherServletに依存していない（SpringMVCに依存しない）
認可の主な対象はURL、メソッド、画面描画の３種類
認証のサーブレットフィルターなど
セキュリティコンテキスト：HTTPSession.ThreadLocalなど
SpringMVCを使わなくても使える
・サーバーを起動しなくてもBeanをテストできる
@before
public void setup()
{
ApplicationContext ctx = new AnnotationConfigApplicationContext(TestConfig.class);
fooserve = ctx.getBean(Fooservice.class);
・Spring Bootが行っていること
必要なJarファイルのダウンロード、
Beanのコンフィグレーション、
サーバーの実行
業務固有のBeanのプログラムつくりは変わらない
組み込みじゃないTomcatにデプロイ可能
・最後に
おすすめ
改訂新版Spring入門
Spring徹底入門
■悩めるJava初心者のためのSpringをどーんとやってみよう
「よい子・悪い子・普通の子」
・自己紹介
よい子のやまざきさん
普通の子 ときさん
わるいこ てらひでさん
・どうやってSpringを勉強したか
よい子
仕事で使うのが一番！SpringOne
苦労：良くも悪くもドキュメントが豊富
普通の子
本を読んで独学。Springを使う開発現場がなかった
わるいこ
勉強などしていない。
勉強しなくても使えるフレームワークがよいフレームワーク
苦労したこと：仕事にならない
・事前に勉強することはあるか
JSP-Servlet、DDDとか
よい子
Reactive！
普通の子
Java文法（例外などのややマイナー部分）
DBまわり、Webまわり、JSP-Servlet、JUnit
→ローカル変数の生成と消滅
わるいこ
男気のある優しい先輩の見分け方
たばこをすうか、おさけをのむか
姉御みたいなひと
→会社にいますか？
バージョンは６の人は
よいこ
８にする
普通の子
わるいこ
いいんだよ、すごくいいんだよ
→８にあげられない場合は
わるいこ：８に使える現場にうつる
Spring初級者になるための勉強範囲は
よいこ
・だめだ、全部だ、ドキュメント全部読め
ふつうのこ
・データアクセス、トランザクション、SPりんｇMVC
わるいこ
・難しいことは全部Springがやってくれる
初心者にぜひ理解してほしいこと、１つ上げるとしたら何
よい子
理解して使うこと！なんとなくでは、正しく動いてないぞ
普通の子
newが１つもなくなるわけではない
だめなこ
Springは開発者が仕事をサボる生産性をあげるための
便利な道具
SpringBootから勉強するのはあり
よいこ
いいんじゃないか。興味を持つため
ふつうのこ
おすすめはしない。何が起こっているかわからない
わるいこ
超おすすめ。Gradle最高！
初級者・中級者になったことは、どう確認すればよいか
よいこ
システム作って、誰かに売る
普通の子
すう画面のWebアプリを自分で設計・実装して、上級者に見てもらう
悪い子
GitHubにソースコードを公開してTwitterで自慢する
発表するのはどのレベル
よいこ
いつでも
普通の子
いつでも
悪い子
難しいことをする前に、ビアハッシュでLTだ
最後の一言
よいこ
JSUGに参加しましょう
普通の子
本を買って・・・
悪い子
こまったら、つぶやく
SpringDay2016
１１月１８日
すごいセッション
全て無料、懇親会、LT
■所感
DIの「依存性」や「AOP」などはソフトウェア工学から来ている用語だと思う。
なので、そこから入らないと、？？？になってしまう。
たとえば、AOPのとことで、「本来すべきでない処理」のところで、
ログ処理が入っているのはいいとして、
「トランザクション処理」は、どうなのどうなの？
いや、それは、しなきゃだめな子な処理でしょ！
これは、「横断的関心事」というソフトウェア工学の概念を
テキトーに言い換えてしまったから起こることで、
ソフトウェア工学的に言うと、
処理は
その機能内で閉じて考えてすべき処理（局所化すべき処理）
その機能内で閉じて考えず、（横断的に考えて）すべき処理（横断的関心事）
にわけられる。
前者は、機能要件で記載されるもので、受注なら受注、発注なら発注のオブジェクトが
担当するというように、担当するオブジェクトが決められ、そのオブジェクトが、他オブジェクト
を監視・制御することで、処理が決定できる。
後者は、主に非機能要件で議論されるもので、受注・発注のみならず、横断的に
調停するオブジェクトが必要となるものである。これが横断的関心事
たとえば、トランザクションは、受注・発注・取引先など、いくつもの機能に
同時にかかわり、矛盾ないように調停しないといけない。これが横断的関心事
ログも、受注と発注が別々だと、わかりにくい（時間がずれてたりすると、
前後関係不明になる）
このほかには、セキュリティなどがある（受注はセキュリティばっちりだけど、
発注はザルとかだと、意味ない）
Diについても、ソフトウェア工学的に、背景がある（文脈＝コンテキスト）
そのへんについては・・・いつか、かく
アクセス
トータル
ランキング
