概要 †
疑問 †
バージョン †
ディレクトリ構造 †
Map/Reduce †
Javadoc †大変便利で、クラスの概要やメソッドの概要を記述しておくと、その情報からHTML形式のドキュメントファイルを生成してくれます。Java Platform SEのAPIリファレンスは実際に、この機能を使って生成しています。 アノテーション †
スレッドプール †
Context †
POM †
Javaのfinal final変数はconstみたいなもの。ぶんかとして 普通の変数と区別するために大文字にすることが多い。 final classは継承付加を表す関数。 ServeletのdoGetとかdoPostとかは当然HTTPリクエストに対応している デザインパターン †Builderパターン †Pythonとかだと引数の名前にたいしてf(name="hoge")とかできるけど、Javaではできない。これを解決したいね、というやつ。 基本的には、インスタンスを直接作るのではなく、作ってくれる大工インスタンスを作る時点でビルダーパターンと言える。 Builderを使いたくなる理由 引数が多くなると、順番を正確に覚えておくのが難しくなる。 つまり引数の渡し間違いが発生しやすくなる 任意の値があると、適当な値をわざわざ渡す記述を書く必要がある。 つまり記述量が無駄に多くなる ↑の例でいうと、 ageは任意の値です。任意だけど、コンストラクタに引数として与えなければならない以上記述はしないといけないですね。無駄なことです。 DAO †In computer software, a data access object (DAO) is an object that provides an abstract interface to some type of database or other persistence mechanism. サーブレット †というかJSPでいじる変数ってsessionに書き込まれたAttributeから得る感じなのか…なるほど Datastoreのkindには_ah_SESSIONというのがあって、javaのセッション管理は自動的にここのkindが使われる Javaのdo filterを考えるときには、二つのフィルタがあってそのあいだの順序はweb.xmlで決める(めんどいし順序に依存しないようにfilterを設計するのが大事) chain.doFilteより上が前処理、下が後処理 フィルタ リクエスト・リスポンスの整形をすることができる。生のリクエストは結構汚いので、サーブレットが処理する前後でいろんなデータ正しい状態にするための機能 FilterChain?のdoFilterメソッドによって一連の処理が実行されるので、これより前で処理を行うか後ろで処理を行うかで、クライアントからの要求と応答のどちら側でフィルタリングを行うか決定する事ができます。 JSP Standard Tag Library (JSTL) Tutorial - 手順としては、
JSPファイル Webサーバ上で動くプログラム Javaの中でもウェブサーバでレスポンシブに動くプログラムをサーブレットと言うらしい。 JSPがpythonでやっていたプログラマブルなHTMLに相当している JSPはServlet containerがJavaServlet?に変換して、その役割で働く Servlet ContainerはServletをspin upしたあと、すぐに落とさない(CGIは寝る)。マシン単体でのスケールアップについて責任を追っているので、マルチスレッド対応している。 サーブレットコンテナとして一番有名なのは「Apache Tomcat」 JavaServer Pages が使われています。これは Java テンプレート エンジンの一種ですが、サーブレットとして実行されます。 getSessionという概念がある。これを使って以下のようにすると、reqにもsessionにもかきこまれるようになるみたい。 req.getSession().setAttribute("cursor", endCursor); req.getSession().setAttribute("page", "list"); Spring †JPAは「Java Persistence (JSR 338)」の略称であり、Java EE標準のO/R MappingおよびDAOの技術仕様です(元々の名称は「Java Persistence API」であり、その略称「JPA」が現在でも一般的に使用されているため、このドキュメントでも「JPA」という名称を使用します)。 ● Entity: 「永続化オブジェクト」を表します。具体的にはデータベースのテーブルと1対1で対応する「Javaのクラス(Entity Class)」およびその「インスタンス(Entity Object)」です。 ちなみに、Java対応統合開発環境の「NetBeans?」を使うと、setter/getterメソッドのコードが自動的に生成されるので便利です。 https://builder.japan.zdnet.com/sp_oracle/35067018/ @Entity public class Employee implements Serializable { Serializableはインスタンスをバイト列に変換できますよ、という明示 EntityManager?は実際のEntityの挿入とか削除とか。「persist(新規登録)」、「merge(更新)」、「remove(削除)」、「find(検索)」という4つのメソッドを覚えておけばよい。create, read, update, and delete (CRUD) 「永続性コンテキスト」はエンティティマネージャ内部のエンティティのキャッシュ。 Repositoryはentidy managerと似たもので、CRUDにするためのメソッドを利用できるようになっている。JpaRepository?を継承しているのと、第一引数にEntityクラス、第二引数にプライマリーキーの型を記述していることがポイントとなります。 Serviceでは、上記のRepositoryを使い、EntityのCRUDを行うメソッドを用意します。今回のような単純なデータ操作なら、パッケージ名をDaoとしてもいいかもしれません。CRUDではなく、もう少し抽象度が高いレベルで行いたい操作をここにかく。そうすることで、Repositoryを使わない実装や抽象化に切り替えることが出来る。 @Service (spring @Transactional (spring) @Autowired 「newしてくれる。@Autowired private MessageRepository? repository;」は「private MessageRepository?=new MesaageRepository?;」と同じ。@Autowiredで、上で作成したRepositoryをインジェクションします。 インジェクションってなに? AOP 何かRESTcontrollerにすると、List型をそのまま返してもいい感じにJSONにしてくれるっぽい。@PathVariable?("id") Long id, @Validated @RequestBody? Whisky whiskyのようにすると、URLの値がPathVariable?として取得でき、RequestBody?がJSONとEntityから自動的に判定されて入力されるらしい。すごい。 https://dev.classmethod.jp/articles/spring-boot_crud-api/ DI 依存性の注入。Springの中心らしいので勉強。 https://www.shookuro.com/entry/2016/08/09/175801 SpringMVCとBootでは@Component の変わりに @Controller、@Service、@Repository を使用するが、これらは実質的に同じ。 @ComponentでSpringコンテナに管理させるクラスとして宣言している。@Autowired を使用してクラスBのインスタンスを Springで自動的にセットしてもらう。 pringのDIコンテナの利点は大きく2つあります。それは、 https://qiita.com/shuntaro_tamura/items/ba5a2e9b3ba305285edd クラスからnew演算子を消せる インスタンス化を1回で済ませられる(Singleton) です。 〜実装〜 実現する方法は2通りあります。 アノテーションを使う Bean定義ファイルを使う です。 アノテーションベースの方のみ説明書きます。 インスタンス変数(注入先の変数)の前に@Autowiredをつけると、@Componentアノテーションのついたクラスの中から該当するものを探し、newしてインスタンスを突っ込んでくれます! これ、結局JavaのクラスはC++とは違って実体ではなく参照に近いので、毎回毎回クラスを書くたびにnewして辛いので、取り決めがあるものについては自動でnewして入れてくれ〜という気持ちっぽい?Componentアノテによって登録し、Autowiredで呼び出す。 AOPはまだ重要じゃなさそうだしいっか。典型的な処理を特定の条件(呼び出し前とか)に呼び出せるようにするための仕組みっぽい。Pointcut(条件)を満たすメソッドに対し、Advice(共通処理)を走らせることで、各クラスには本質的な処理だけを記述することが可能となるわけです。https://qiita.com/shuntaro_tamura/items/ba5a2e9b3ba305285edd @Beanと書いたメソッドでインスタンス化されたクラスがシングルトンクラスとしてDIコンテナに登録される。任意のクラスで@Autowiredで注入してアクセスできる。 BeanとComponentの差は? Bean=インスタンス化して使用するクラスです。 Spring FrameworkがXML地獄で面倒だが、Bootではアノテーション方式でBeanが設定できるので楽 制御の反転、という用語があるが、これはDIと同義。DIは結局、依存関係が合った時にそれを自動的に解決してインスタンスを作成してくれるもの。DIコンテナ=IoCコンテナ https://ja.wikipedia.org/wiki/%E5%88%B6%E5%BE%A1%E3%81%AE%E5%8F%8D%E8%BB%A2 JavaBeans?とSpringのBeanは違う!!! Spring の IoC コンテナによって管理されるオブジェクトを Bean と呼ぶ。JavaBeans? とは違う。 Spring の設定とは、すなわち Bean の設定のことを指す。 どのような Bean を定義するか Bean にどのようなプロパティを与えるか Bean をどのように初期化するか Bean をどのように破棄するか どの Bean と Bean をつなげるか といった設定を IoC コンテナに食わせると、IoC コンテナは Bean のオブジェクトツリーを構築し、適切に生成/破棄を行う。(https://software.fujitsu.com/jp/manual/manualfiles/M050000/J2X11190/01/guide05/guide054.html オブジェクトツリーはxmlを見るとよりわかりやすい。@Beanは動的生成にすぎないっぽい。どうやらシングルトンを前計算で木構造状に作り、@Autowiredでは前計算したオブジェクトの参照をメンバ変数に貼り付けているようなイメージ?) Bean のライフサイクルは IoC コンテナによって管理される。デフォルトでは、コンテナの起動時にインスタンス化され、シングルトンとして扱われる。すなわちひとつのオブジェクトが全ての場所で共有される。そしてコンテナの終了とともに、インスタンスも破棄される。 デフォルトで用意されているスコープは以下の通り: singleton シングルトン。デフォルト prototype ApplicationContext?.getBean するたびに new する。 Beanによって木構造を作っているらしい。なるほど。 @Component はクラスにつけるアノテーションである。このアノテーションをつけたクラスが、IoC コンテナの管理対象であることを知らせるためのマーカーである。@Component がついたクラスは @Bean による Bean 定義を書かずとも、IoC コンテナの管理対象になる。同じような役割の Bean が大量にある場合には、いちいち @Configuration + @Bean で Bean を定義していくよりも手軽で使いでがある。 Beanはクラスである、と書かれていたのに突然Beanをメソッドにつけるとか言われて混乱している 典型的なコンポーネントとして、3 つのステレオタイプが用意されている: @Controller Web アプリケーションのコントローラクラスであることを表す @Service サービス層のクラスであることを表す(サービス層って何???) @Repository ある DB に、DB 特有・に依存したアクセス方法 (SQL クエリとか) を知らなくともCRUDを行えるようにするためのもの https://terasolunaorg.github.io/guideline/5.0.1.RELEASE/ja/ImplementationAtEachLayer/DomainLayer.html#repository Entity-Service-Repositoryが永続化系のセット。EntiryはDBに書かれるべきデータと等価なもの。Serviceはどういう風にEntityを永続化するかを決める。そのためにServiceはDBごとに定義されたRepositoryを介して、Entityをインフラストラクチャレイヤに送る。インフラストラクチャは、Entityとそれに対して行いたい根源的な操作を実装していて、これはJavaのクラスであるEntityをSQL文に変換して実際にDBにAPIコールすることによって実装する。SQLの場合、エンティティのクラスごとにRepositoryを作らないといけない。でもエンティティのクラスが増えても、サービスは1個だけとかでも全然良い。 Persistence layer : 実際のRDBMS Infrastracture layer : クラス定義と SQL のテーブル定義の差を吸収するためのレイヤ。これを吸収するのはRepositoryImpl?と呼ばれるもの。 Domain layer = クラスへの代入とオブジェクトの「永続化して!」くらいの雑な指示で DB に書き込めるくらいの抽象度があるレイヤ。Infrastructure layer のおかげでこんなマジカルなことが出来る。 Repositoryを設ける最も重要な目的は、永続先に依存するロジックを、業務ロジックから排除することではないという点である。 最も重要な目的は、業務データへアクセスするための操作をRepositoryへ分離することで、業務ロジック(Service)の実装範囲をビジネスルールに関する実装に専念させるという点である。 結果として、永続先に依存するロジックは業務ロジック(Service)ではなく、Repository側に実装される事になる。 Spring でのデータベース抽象化の勉強をしていたらこんな時間になってしまった… とりあえず Bean がシングルトンを前処理で全部作って参照の木構造を構築することで O(1) でインスタンスにアクセスできてるっぽい?ことと、DB 特有のクエリなどを Infrastructure Layer で吸収して、吸収後の操作はJava のインスタンスをいつでも使えるようにして!くらいの雑な CRUD 操作だけにした状態で Repository としてサービスが使えるようにしとく、みたいなイメージ POJO(Plain Old Java Object)は要するにnewで実体化される普通のオブジェクトのこと printf とテキストデータを送るための配線がないから全部自前で作らないと!みたいな自前世界から来た自作星人なので、ちゃんと諸々が整っているのにびっくりしてしまいます。 概念としては HAL みたいですねという感じで自然だけど、僕の今までの認識ではこういう Repository に相当するものは自前で実装しなければいけないと勘違いしていたので、この辺の労力を全部フレームワークが吸収してくれているというのは非常に助かる of 助かるですね。 DB 特有のクエリなどを Infrastructure Layer で吸収して、吸収後の操作はJava のインスタンスをいつでも使えるようにして!くらいの雑な CRUD 操作だけにした状態で Repository としてサービスが使えるようにしとく、みたいなイメージ Spring でのデータベース抽象化の勉強をしていたらこんな時間になってしまった… とりあえず Bean がシングルトンを前処理で全部作って参照の木構造を構築することで O(1) でインスタンスにアクセスできてるっぽい? https://terasolunaorg.github.io/guideline/5.0.1.RELEASE/ja/ImplementationAtEachLayer/DomainLayer.html#repository このサイトがめちゃくちゃ詳しくSpringについて書いてあってこれを読むだけで強く慣れそう。本革なくとも intelliJ †メソッドのコードや定義の確認のためにはC-bで行ける(Alt-Leftかも) intellliJで、文字列リテラルにs: とかo:とかついているのは、呼び出し元の型がstringかObjectかという違いによるもの というか関数の中の変数としてthisを渡していたりするときも、それがどの方7日がわからなくならないようにbuilder:とかがついている
Jetty †
未整理 †
|